<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en-GB">
	<id>https://wiki.de4a.eu/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Ictu+mavi.cristache</id>
	<title>DE4A - User contributions [en-gb]</title>
	<link rel="self" type="application/atom+xml" href="https://wiki.de4a.eu/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Ictu+mavi.cristache"/>
	<link rel="alternate" type="text/html" href="https://wiki.de4a.eu/index.php/Special:Contributions/Ictu_mavi.cristache"/>
	<updated>2026-04-05T17:06:42Z</updated>
	<subtitle>User contributions</subtitle>
	<generator>MediaWiki 1.35.1</generator>
	<entry>
		<id>https://wiki.de4a.eu/index.php?title=Disclaimer&amp;diff=5981</id>
		<title>Disclaimer</title>
		<link rel="alternate" type="text/html" href="https://wiki.de4a.eu/index.php?title=Disclaimer&amp;diff=5981"/>
		<updated>2023-04-03T17:10:53Z</updated>

		<summary type="html">&lt;p&gt;Ictu mavi.cristache: Ictu mavi.cristache moved page Disclaimer to Legal disclaimer and copyrights: Page name modified to match adjusted content&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;#REDIRECT [[Legal disclaimer and copyrights]]&lt;/div&gt;</summary>
		<author><name>Ictu mavi.cristache</name></author>
	</entry>
	<entry>
		<id>https://wiki.de4a.eu/index.php?title=Legal_disclaimer_and_copyrights&amp;diff=5980</id>
		<title>Legal disclaimer and copyrights</title>
		<link rel="alternate" type="text/html" href="https://wiki.de4a.eu/index.php?title=Legal_disclaimer_and_copyrights&amp;diff=5980"/>
		<updated>2023-04-03T17:10:53Z</updated>

		<summary type="html">&lt;p&gt;Ictu mavi.cristache: Ictu mavi.cristache moved page Disclaimer to Legal disclaimer and copyrights: Page name modified to match adjusted content&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Legal disclaimer ==&lt;br /&gt;
This DE4A wiki is created, hosted and maintained by and on behalf of the members of the DE4A consortium (see [https://www.de4a.eu/consortium https://www.de4a.eu/consortium]). All contents are provided in good faith by persons supporting this consortium, with the common objective of furthering the progress of the DE4A project.&lt;br /&gt;
 &lt;br /&gt;
Anyone with appropriate credentials may choose to add or edit contents of the DE4A wiki. Any contributions to the content remain owned by the respective contributor(s), but by submitting any contents, you explicitly authorise the DE4A consortium to publish and disseminate the contents via the wiki under the licensing terms set out below. &lt;br /&gt;
 &lt;br /&gt;
Additionally to this license, you (as a contributor) also authorise the members of the DE4A consortium to use your contents for any purposes (including usage outside of this wiki) that would benefit the execution of the DE4A project. &lt;br /&gt;
 &lt;br /&gt;
Each contributor should apply reasonable care to verify that their contributions are likely to contribute to the progress of the DE4A project, given the expertise and knowledge of the contributor and the state of the project. In case of doubts on this point, the contributor should take care to communicate any applicable constraints or reservations in the contribution. Each contributor is responsible for ensuring that their individual contributions are lawful, including but not limited to ensuring that contributions do not violate any third party intellectual property rights.&lt;br /&gt;
 &lt;br /&gt;
Irrespective of the above, contents are provided purely on an ‘as is’ basis, without any guarantees of accuracy, completeness or usability for any particular purpose. Contents do not necessarily reflect a consensus or a shared position of the DE4A consortium as a whole, nor even of any individual member. Anyone who decides to rely on the contents of the DE4A wiki for any reason or purpose should apply their own diligence, and assumes full and exclusive responsibility and liability for any consequences of their reliance on the contents. No assurances are provided with respect to the contents, neither explicitly nor implied.&lt;br /&gt;
&lt;br /&gt;
== Copyrights ==&lt;br /&gt;
Except where otherwise indicated, all direct texts and graphical contents of this DE4A wiki are made available to you under the [https://creativecommons.org/licenses/by/4.0/ Creative Commons -  Attribution 4.0 International (CC BY 4.0) license] by the respective authors. &lt;br /&gt;
&lt;br /&gt;
Note that this license only applies to the text elements directly located on the individual wiki pages, and to any graphical images embedded as content into these pages. &lt;br /&gt;
&lt;br /&gt;
The license does not apply to any documents that are linked to on the wiki pages (irrespective of whether they are internally hosted on the de4a.eu domain, or externally hosted on another domain). For licensing information on such documents, please consult the documents themselves. In accordance with the legal disclaimer above, DE4A offers no assurances and accepts no liabilities with respect to the licensing terms of such documents.&lt;/div&gt;</summary>
		<author><name>Ictu mavi.cristache</name></author>
	</entry>
	<entry>
		<id>https://wiki.de4a.eu/index.php?title=MediaWiki:Sidebar&amp;diff=4397</id>
		<title>MediaWiki:Sidebar</title>
		<link rel="alternate" type="text/html" href="https://wiki.de4a.eu/index.php?title=MediaWiki:Sidebar&amp;diff=4397"/>
		<updated>2022-02-07T14:45:02Z</updated>

		<summary type="html">&lt;p&gt;Ictu mavi.cristache: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;* navigation&lt;br /&gt;
** mainpage|mainpage-description&lt;br /&gt;
** Disclaimer|Disclaimer&lt;br /&gt;
** recentchanges-url|recentchanges&lt;br /&gt;
** randompage-url|randompage&lt;br /&gt;
** helppage|help-mediawiki&lt;br /&gt;
&lt;br /&gt;
*DE4A Documentation&lt;br /&gt;
**Pilots|Pilots&lt;br /&gt;
**Reference Architecture|Reference Architecture&lt;br /&gt;
**Library of components and building blocks|Components and building blocks&lt;br /&gt;
**DE4A Semantic interoperability|Semantic solutions&lt;br /&gt;
**DE4A Common Components|Common components&lt;br /&gt;
&lt;br /&gt;
*Other&lt;br /&gt;
**Getting started|Getting started&lt;br /&gt;
**Special:ListFiles|Files&lt;br /&gt;
**Glossary|Glossary&lt;br /&gt;
&lt;br /&gt;
* SEARCH&lt;br /&gt;
* TOOLBOX&lt;br /&gt;
* LANGUAGES&lt;/div&gt;</summary>
		<author><name>Ictu mavi.cristache</name></author>
	</entry>
	<entry>
		<id>https://wiki.de4a.eu/index.php?title=MediaWiki:Sidebar&amp;diff=4395</id>
		<title>MediaWiki:Sidebar</title>
		<link rel="alternate" type="text/html" href="https://wiki.de4a.eu/index.php?title=MediaWiki:Sidebar&amp;diff=4395"/>
		<updated>2022-02-07T14:44:37Z</updated>

		<summary type="html">&lt;p&gt;Ictu mavi.cristache: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;* navigation&lt;br /&gt;
** mainpage|mainpage-description&lt;br /&gt;
** Disclaimer|Disclaimer&lt;br /&gt;
** recentchanges-url|recentchanges&lt;br /&gt;
** randompage-url|randompage&lt;br /&gt;
** helppage|help-mediawiki&lt;br /&gt;
&lt;br /&gt;
*DE4A Documentation&lt;br /&gt;
**Pilots|Pilots&lt;br /&gt;
**Reference Architecture|Reference Architecture&lt;br /&gt;
**Library of components and building blocks|Components and building blocks&lt;br /&gt;
**Semantic solutions|DE4A Semantic interoperability&lt;br /&gt;
**Common components|DE4A Common Components&lt;br /&gt;
&lt;br /&gt;
*Other&lt;br /&gt;
**Getting started|Getting started&lt;br /&gt;
**Special:ListFiles|Files&lt;br /&gt;
**Glossary|Glossary&lt;br /&gt;
&lt;br /&gt;
* SEARCH&lt;br /&gt;
* TOOLBOX&lt;br /&gt;
* LANGUAGES&lt;/div&gt;</summary>
		<author><name>Ictu mavi.cristache</name></author>
	</entry>
	<entry>
		<id>https://wiki.de4a.eu/index.php?title=MediaWiki:Sidebar&amp;diff=4393</id>
		<title>MediaWiki:Sidebar</title>
		<link rel="alternate" type="text/html" href="https://wiki.de4a.eu/index.php?title=MediaWiki:Sidebar&amp;diff=4393"/>
		<updated>2022-02-07T14:43:50Z</updated>

		<summary type="html">&lt;p&gt;Ictu mavi.cristache: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;* navigation&lt;br /&gt;
** mainpage|mainpage-description&lt;br /&gt;
** Disclaimer|Disclaimer&lt;br /&gt;
** recentchanges-url|recentchanges&lt;br /&gt;
** randompage-url|randompage&lt;br /&gt;
** helppage|help-mediawiki&lt;br /&gt;
&lt;br /&gt;
*DE4A Documentation&lt;br /&gt;
**Pilots|Pilots&lt;br /&gt;
**Reference Architecture|Reference Architecture&lt;br /&gt;
**Library of components and building blocks|Components and building blocks&lt;br /&gt;
**Semantic solutions&lt;br /&gt;
**Common components&lt;br /&gt;
&lt;br /&gt;
*Other&lt;br /&gt;
**Getting started|Getting started&lt;br /&gt;
**Special:ListFiles|Files&lt;br /&gt;
**Glossary|Glossary&lt;br /&gt;
&lt;br /&gt;
* SEARCH&lt;br /&gt;
* TOOLBOX&lt;br /&gt;
* LANGUAGES&lt;/div&gt;</summary>
		<author><name>Ictu mavi.cristache</name></author>
	</entry>
	<entry>
		<id>https://wiki.de4a.eu/index.php?title=DE4A_Service_Interoperability_Solutions_Toolbox&amp;diff=4389</id>
		<title>DE4A Service Interoperability Solutions Toolbox</title>
		<link rel="alternate" type="text/html" href="https://wiki.de4a.eu/index.php?title=DE4A_Service_Interoperability_Solutions_Toolbox&amp;diff=4389"/>
		<updated>2022-02-07T14:30:52Z</updated>

		<summary type="html">&lt;p&gt;Ictu mavi.cristache: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;__NOTOC__&lt;br /&gt;
&lt;br /&gt;
This toolbox is the central, long-term deliverable of the DE4A Architecture work package and takes the form of a structured, online architecture repository that extends from the content of the Architecture Framework and prior work of e-SENS. The toolbox includes (pointers to) prior work in CEF, ISA, ISA&amp;lt;sup&amp;gt;2&amp;lt;/sup&amp;gt; and prior LSPs. It includes new DE4A common components and implementation method and Pilot insights.  &lt;br /&gt;
&lt;br /&gt;
The image below has clickable sections to jump to other pages like, the DE4A Reference Architecture, patterns, Semantic Solutions, Common Components and Building Blocks. &lt;br /&gt;
&lt;br /&gt;
&amp;lt;imagemap&amp;gt;&lt;br /&gt;
File:Service_Interoperability_Solutions_Toolbox.png|thumb|center|900x900px|Clicking on an area in the picture causes the browser to load the appropriate wiki page.&lt;br /&gt;
&lt;br /&gt;
rect 455 124 541 590 [[Intermediation_Pattern|Intermediation pattern]]&lt;br /&gt;
rect 558 103 651 562 [[User-supported_Intermediation_Pattern|USI pattern]]&lt;br /&gt;
rect 672 78 750 548 [[Verifiable_Credentials_Pattern|VC pattern]]&lt;br /&gt;
rect 765 57 853 523 [[Subscription_and_Notification_Pattern|S&amp;amp;N pattern]]&lt;br /&gt;
rect 868 50 960 516 [[Lookup_Pattern|LKP pattern]]&lt;br /&gt;
rect 366 36 441 619 [[Reference_Architecture|Reference Architecture]]&lt;br /&gt;
rect 992 57 2159 587 [[Application_Services|Application Services]]&lt;br /&gt;
rect 324 640 2571 697 [[Pilots|DE4A Pilots]]&lt;br /&gt;
rect 651 743 1209 992 [[DE4A_Semantic_interoperability|Semantic solutions]]&lt;br /&gt;
rect 1287 740 1835 989 [[DE4A Common Components|Common Components]]&lt;br /&gt;
rect 1920 747 2468 992 [[Building_Blocks|Building Blocks]]&lt;br /&gt;
&lt;br /&gt;
desc bottom-right&lt;br /&gt;
&amp;lt;/imagemap&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== [[Pilots]] ==&lt;br /&gt;
DE4A includes three cross-border and cross-domain [[Pilots]] - &amp;lt;span style=&amp;quot;background:#00FF00&amp;quot;&amp;gt;[[Studying Abroad Pilot]]&amp;lt;/span&amp;gt;, &amp;lt;span style=&amp;quot;background:#FFFF00&amp;quot;&amp;gt;[[Doing Business Abroad Pilot]]&amp;lt;/span&amp;gt;, and &amp;lt;span style=&amp;quot;background:#00FFFF&amp;quot;&amp;gt;[[Moving Abroad Pilot]]&amp;lt;/span&amp;gt; -, comprising different functional use cases focused on different high-impact and viable administrative procedures, and aimed to realize tangible benefits in fully operational environments to real users (citizens, students, business persons and public servants). The Pilots are delivered by a separate, agile, multi-disciplinary, inter-member state teams of experts. The focus of these teams is on iterative system integration and configuration, hence on making existing building blocks and solutions work together in real life cases.&lt;br /&gt;
&lt;br /&gt;
== [[Reference Architecture|Reference Architecture]] ==&lt;br /&gt;
DE4A developed a multi-pattern architecture for eGovernment interoperability with a focus on digital-by-default procedures for citizens and businesses and the full implementation of the Once-Only Principle. It provides guidance to the DE4A pilots and to  projects seeking to implement cross-border once-only enabled eProcedures. &lt;br /&gt;
&lt;br /&gt;
== [[Library of components and  building blocks]] ==&lt;br /&gt;
&lt;br /&gt;
This section contains the collection components and candidate Building Blocks. The classification of this library follows the DE4A [[Reference Architecture]], starting on the highest level of architecture components: the Application Collaborations. These Application collaborations are aggregations of Application components, Data objects and Interfaces.  &lt;br /&gt;
&lt;br /&gt;
The reference architecture at conceptional/functional level is completed with a catalogue of candidate building blocks mapped to required Application Services that they are intended to deliver in the context of each pilot.  &lt;br /&gt;
&lt;br /&gt;
==DE4A Solutions==&lt;br /&gt;
The DE4A Solutions are split in Semantic Interoperability Solutions and Common Components. The first deals with semantic specifications, the second with SW components. There is also a link related to development and testing activities. &lt;br /&gt;
&lt;br /&gt;
==== [[DE4A Semantic interoperability|Semantic Interoperability Solutions]] ====&lt;br /&gt;
&lt;br /&gt;
==== [[DE4A Common Components]] ====&lt;br /&gt;
== Legal and ethical support ==&lt;br /&gt;
DE4A also provides a [[Legal and ethical analysis]]. &lt;br /&gt;
&lt;br /&gt;
(Inputs and suggestions can be provided on the subpage)&lt;br /&gt;
&lt;br /&gt;
[[Category:wip]]&lt;/div&gt;</summary>
		<author><name>Ictu mavi.cristache</name></author>
	</entry>
	<entry>
		<id>https://wiki.de4a.eu/index.php?title=DE4A_Service_Interoperability_Solutions_Toolbox&amp;diff=4259</id>
		<title>DE4A Service Interoperability Solutions Toolbox</title>
		<link rel="alternate" type="text/html" href="https://wiki.de4a.eu/index.php?title=DE4A_Service_Interoperability_Solutions_Toolbox&amp;diff=4259"/>
		<updated>2022-02-01T09:33:38Z</updated>

		<summary type="html">&lt;p&gt;Ictu mavi.cristache: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;__NOTOC__&lt;br /&gt;
&lt;br /&gt;
This toolbox is the central, long-term deliverable of the DE4A Architecture work package (WP2) and takes the form of a structured, online architecture repository that extends from the content of the Architecture Framework and prior work of e-SENS. The toolbox includes (pointers to) prior work in CEF, ISA, ISA&amp;lt;sup&amp;gt;2&amp;lt;/sup&amp;gt; and prior LSPs. It includes new DE4A common components and implementation method and Pilot insights. &lt;br /&gt;
&lt;br /&gt;
&amp;lt;imagemap&amp;gt;&lt;br /&gt;
File:Service_Interoperability_Solutions_Toolbox.png|thumb|center|900x900px|Clicking on an area in the picture causes the browser to load the appropriate wiki page.&lt;br /&gt;
&lt;br /&gt;
rect 455 124 541 590 [[Intermediation_Pattern|Intermediation pattern]]&lt;br /&gt;
rect 558 103 651 562 [[User-supported_Intermediation_Pattern|USI pattern]]&lt;br /&gt;
rect 672 78 750 548 [[Verifiable_Credentials_Pattern|VC pattern]]&lt;br /&gt;
rect 765 57 853 523 [[Subscription_and_Notification_Pattern|S&amp;amp;N pattern]]&lt;br /&gt;
rect 868 50 960 516 [[Lookup_Pattern|LKP pattern]]&lt;br /&gt;
rect 366 36 441 619 [[Reference_Architecture|Reference Architecture]]&lt;br /&gt;
rect 992 57 2159 587 [[Application_Services|Application Services]]&lt;br /&gt;
rect 324 640 2571 697 [[Pilots|DE4A Pilots]]&lt;br /&gt;
rect 651 743 1209 992 [[DE4A_Semantic_interoperability|Semantic solutions]]&lt;br /&gt;
rect 1287 740 1835 989 [[Category:WP5|Common Components]]&lt;br /&gt;
rect 1920 747 2468 992 [[Building_Blocks|Building Blocks]]&lt;br /&gt;
&lt;br /&gt;
desc bottom-right&lt;br /&gt;
&amp;lt;/imagemap&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== [[Pilots]] ==&lt;br /&gt;
DE4A includes three cross-border and cross-domain [[Pilots]] - &amp;lt;span style=&amp;quot;background:#00FF00&amp;quot;&amp;gt;[[Studying Abroad Pilot]]&amp;lt;/span&amp;gt;, &amp;lt;span style=&amp;quot;background:#FFFF00&amp;quot;&amp;gt;[[Doing Business Abroad Pilot]]&amp;lt;/span&amp;gt;, and &amp;lt;span style=&amp;quot;background:#00FFFF&amp;quot;&amp;gt;[[Moving Abroad Pilot]]&amp;lt;/span&amp;gt; -, comprising different functional use cases focused on different high-impact and viable administrative procedures, and aimed to realize tangible benefits in fully operational environments to real users (citizens, students, business persons and public servants). The Pilots are delivered by a separate, agile, multi-disciplinary, inter-member state teams of experts. The focus of these teams is on iterative system integration and configuration, hence on making existing building blocks and solutions work together in real life cases.&lt;br /&gt;
&lt;br /&gt;
== [[Reference Architecture|Reference Architecture]] ==&lt;br /&gt;
DE4A developed a multi-pattern architecture for eGovernment interoperability with a focus on digital-by-default procedures for citizens and businesses and the full implementation of the Once-Only Principle. It provides guidance to the DE4A pilots and to  projects seeking to implement cross-border once-only enabled eProcedures. &lt;br /&gt;
&lt;br /&gt;
== [[Library of components and  building blocks]] ==&lt;br /&gt;
&lt;br /&gt;
This section contains the collection components and candidate Building Blocks. The classification of this library follows the DE4A [[Reference Architecture]], starting on the highest level of architecture components: the Application Collaborations. These Application collaborations are aggregations of Application components, Data objects and Interfaces.  &lt;br /&gt;
&lt;br /&gt;
The reference architecture at conceptional/functional level is completed with a catalogue of candidate building blocks mapped to required Application Services that they are intended to deliver in the context of each pilot.  &lt;br /&gt;
&lt;br /&gt;
==DE4A Solutions==&lt;br /&gt;
The DE4A Solutions are split in Semantic Interoperability Solutions and Common Components. The first deals with semantic specifications, the second with SW components. There is also a link related to development and testing activities. &lt;br /&gt;
&lt;br /&gt;
[[DE4A Semantic interoperability|Semantic Interoperability Solutions]]&lt;br /&gt;
&lt;br /&gt;
[[WP5|Common Components]]&lt;br /&gt;
&lt;br /&gt;
[[DE4A Development and Testing]]&lt;br /&gt;
&lt;br /&gt;
== Legal and ethical support ==&lt;br /&gt;
DE4A also provides a [[Legal and ethical analysis]]. &lt;br /&gt;
&lt;br /&gt;
(Inputs and suggestions can be provided on the subpage)&lt;br /&gt;
&lt;br /&gt;
[[Category:wip]]&lt;/div&gt;</summary>
		<author><name>Ictu mavi.cristache</name></author>
	</entry>
	<entry>
		<id>https://wiki.de4a.eu/index.php?title=DE4A_Service_Interoperability_Solutions_Toolbox&amp;diff=4258</id>
		<title>DE4A Service Interoperability Solutions Toolbox</title>
		<link rel="alternate" type="text/html" href="https://wiki.de4a.eu/index.php?title=DE4A_Service_Interoperability_Solutions_Toolbox&amp;diff=4258"/>
		<updated>2022-02-01T09:30:47Z</updated>

		<summary type="html">&lt;p&gt;Ictu mavi.cristache: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;__NOTOC__&lt;br /&gt;
&lt;br /&gt;
This toolbox is the central, long-term deliverable of the DE4A Architecture work package (WP2) and takes the form of a structured, online architecture repository that extends from the content of the Architecture Framework and prior work of e-SENS. The toolbox includes (pointers to) prior work in CEF, ISA, ISA&amp;lt;sup&amp;gt;2&amp;lt;/sup&amp;gt; and prior LSPs. It includes new DE4A common components and implementation method and Pilot insights. &lt;br /&gt;
&lt;br /&gt;
&amp;lt;imagemap&amp;gt;&lt;br /&gt;
File:Service_Interoperability_Solutions_Toolbox.png|thumb|center|900x900px|Clicking on an area in the picture causes the browser to load the appropriate wiki page.&lt;br /&gt;
&lt;br /&gt;
rect 455 124 541 590 [[https://wiki.de4a.eu/index.php/Intermediation_Pattern|Intermediation pattern]]&lt;br /&gt;
rect 558 103 651 562 [[https://wiki.de4a.eu/index.php/User-supported_Intermediation_Pattern|USI pattern]]&lt;br /&gt;
rect 672 78 750 548 [[https://wiki.de4a.eu/index.php/Verifiable_Credentials_Pattern|VC pattern]]&lt;br /&gt;
rect 765 57 853 523 [[https://wiki.de4a.eu/index.php/Subscription_and_Notification_Pattern|S&amp;amp;N pattern]]&lt;br /&gt;
rect 868 50 960 516 [[https://wiki.de4a.eu/index.php/Lookup_Pattern|LKP pattern]]&lt;br /&gt;
rect 366 36 441 619 [[https://wiki.de4a.eu/index.php/Reference_Architecture|Reference Architecture]]&lt;br /&gt;
rect 992 57 2159 587 [[https://wiki.de4a.eu/index.php/Application_Services|Application Services]]&lt;br /&gt;
rect 324 640 2571 697 [[https://wiki.de4a.eu/index.php/Pilots|DE4A Pilots]]&lt;br /&gt;
rect 651 743 1209 992 [[https://wiki.de4a.eu/index.php/DE4A_Semantic_interoperability|Semantic solutions]]&lt;br /&gt;
rect 1287 740 1835 989 [[https://wiki.de4a.eu/index.php/Category:WP5|Common Components]]&lt;br /&gt;
rect 1920 747 2468 992 [[https://wiki.de4a.eu/index.php/Building_Blocks|Building Blocks]]&lt;br /&gt;
&lt;br /&gt;
desc bottom-right&lt;br /&gt;
&amp;lt;/imagemap&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== [[Pilots]] ==&lt;br /&gt;
DE4A includes three cross-border and cross-domain [[Pilots]] - &amp;lt;span style=&amp;quot;background:#00FF00&amp;quot;&amp;gt;[[Studying Abroad Pilot]]&amp;lt;/span&amp;gt;, &amp;lt;span style=&amp;quot;background:#FFFF00&amp;quot;&amp;gt;[[Doing Business Abroad Pilot]]&amp;lt;/span&amp;gt;, and &amp;lt;span style=&amp;quot;background:#00FFFF&amp;quot;&amp;gt;[[Moving Abroad Pilot]]&amp;lt;/span&amp;gt; -, comprising different functional use cases focused on different high-impact and viable administrative procedures, and aimed to realize tangible benefits in fully operational environments to real users (citizens, students, business persons and public servants). The Pilots are delivered by a separate, agile, multi-disciplinary, inter-member state teams of experts. The focus of these teams is on iterative system integration and configuration, hence on making existing building blocks and solutions work together in real life cases.&lt;br /&gt;
&lt;br /&gt;
== [[Reference Architecture|Reference Architecture]] ==&lt;br /&gt;
DE4A developed a multi-pattern architecture for eGovernment interoperability with a focus on digital-by-default procedures for citizens and businesses and the full implementation of the Once-Only Principle. It provides guidance to the DE4A pilots and to  projects seeking to implement cross-border once-only enabled eProcedures. &lt;br /&gt;
&lt;br /&gt;
== [[Library of components and  building blocks]] ==&lt;br /&gt;
&lt;br /&gt;
This section contains the collection components and candidate Building Blocks. The classification of this library follows the DE4A [[Reference Architecture]], starting on the highest level of architecture components: the Application Collaborations. These Application collaborations are aggregations of Application components, Data objects and Interfaces.  &lt;br /&gt;
&lt;br /&gt;
The reference architecture at conceptional/functional level is completed with a catalogue of candidate building blocks mapped to required Application Services that they are intended to deliver in the context of each pilot.  &lt;br /&gt;
&lt;br /&gt;
==DE4A Solutions==&lt;br /&gt;
The DE4A Solutions are split in Semantic Interoperability Solutions and Common Components. The first deals with semantic specifications, the second with SW components. There is also a link related to development and testing activities. &lt;br /&gt;
&lt;br /&gt;
[[DE4A Semantic interoperability|Semantic Interoperability Solutions]]&lt;br /&gt;
&lt;br /&gt;
[[WP5|Common Components]]&lt;br /&gt;
&lt;br /&gt;
[[DE4A Development and Testing]]&lt;br /&gt;
&lt;br /&gt;
== Legal and ethical support ==&lt;br /&gt;
DE4A also provides a [[Legal and ethical analysis]]. &lt;br /&gt;
&lt;br /&gt;
(Inputs and suggestions can be provided on the subpage)&lt;br /&gt;
&lt;br /&gt;
[[Category:wip]]&lt;/div&gt;</summary>
		<author><name>Ictu mavi.cristache</name></author>
	</entry>
	<entry>
		<id>https://wiki.de4a.eu/index.php?title=DE4A_Service_Interoperability_Solutions_Toolbox&amp;diff=4257</id>
		<title>DE4A Service Interoperability Solutions Toolbox</title>
		<link rel="alternate" type="text/html" href="https://wiki.de4a.eu/index.php?title=DE4A_Service_Interoperability_Solutions_Toolbox&amp;diff=4257"/>
		<updated>2022-02-01T09:25:11Z</updated>

		<summary type="html">&lt;p&gt;Ictu mavi.cristache: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;__NOTOC__&lt;br /&gt;
&lt;br /&gt;
This toolbox is the central, long-term deliverable of the DE4A Architecture work package (WP2) and takes the form of a structured, online architecture repository that extends from the content of the Architecture Framework and prior work of e-SENS. The toolbox includes (pointers to) prior work in CEF, ISA, ISA&amp;lt;sup&amp;gt;2&amp;lt;/sup&amp;gt; and prior LSPs. It includes new DE4A common components and implementation method and Pilot insights. &lt;br /&gt;
[[File:Service Interoperability Solutions Toolbox.png|center|frameless|900x900px]] &lt;br /&gt;
&lt;br /&gt;
== [[Pilots]] ==&lt;br /&gt;
DE4A includes three cross-border and cross-domain [[Pilots]] - &amp;lt;span style=&amp;quot;background:#00FF00&amp;quot;&amp;gt;[[Studying Abroad Pilot]]&amp;lt;/span&amp;gt;, &amp;lt;span style=&amp;quot;background:#FFFF00&amp;quot;&amp;gt;[[Doing Business Abroad Pilot]]&amp;lt;/span&amp;gt;, and &amp;lt;span style=&amp;quot;background:#00FFFF&amp;quot;&amp;gt;[[Moving Abroad Pilot]]&amp;lt;/span&amp;gt; -, comprising different functional use cases focused on different high-impact and viable administrative procedures, and aimed to realize tangible benefits in fully operational environments to real users (citizens, students, business persons and public servants). The Pilots are delivered by a separate, agile, multi-disciplinary, inter-member state teams of experts. The focus of these teams is on iterative system integration and configuration, hence on making existing building blocks and solutions work together in real life cases.&lt;br /&gt;
&lt;br /&gt;
== [[Reference Architecture|Reference Architecture]] ==&lt;br /&gt;
DE4A developed a multi-pattern architecture for eGovernment interoperability with a focus on digital-by-default procedures for citizens and businesses and the full implementation of the Once-Only Principle. It provides guidance to the DE4A pilots and to  projects seeking to implement cross-border once-only enabled eProcedures. &lt;br /&gt;
&lt;br /&gt;
== [[Library of components and  building blocks]] ==&lt;br /&gt;
&lt;br /&gt;
This section contains the collection components and candidate Building Blocks. The classification of this library follows the DE4A [[Reference Architecture]], starting on the highest level of architecture components: the Application Collaborations. These Application collaborations are aggregations of Application components, Data objects and Interfaces.  &lt;br /&gt;
&lt;br /&gt;
The reference architecture at conceptional/functional level is completed with a catalogue of candidate building blocks mapped to required Application Services that they are intended to deliver in the context of each pilot.  &lt;br /&gt;
&lt;br /&gt;
==DE4A Solutions==&lt;br /&gt;
The DE4A Solutions are split in Semantic Interoperability Solutions and Common Components. The first deals with semantic specifications, the second with SW components. There is also a link related to development and testing activities. &lt;br /&gt;
&lt;br /&gt;
[[DE4A Semantic interoperability|Semantic Interoperability Solutions]]&lt;br /&gt;
&lt;br /&gt;
[[WP5|Common Components]]&lt;br /&gt;
&lt;br /&gt;
[[DE4A Development and Testing]]&lt;br /&gt;
&lt;br /&gt;
== Legal and ethical support ==&lt;br /&gt;
DE4A also provides a [[Legal and ethical analysis]]. &lt;br /&gt;
&lt;br /&gt;
(Inputs and suggestions can be provided on the subpage)&lt;br /&gt;
&lt;br /&gt;
[[Category:wip]]&lt;/div&gt;</summary>
		<author><name>Ictu mavi.cristache</name></author>
	</entry>
	<entry>
		<id>https://wiki.de4a.eu/index.php?title=DE4A_Service_Interoperability_Solutions_Toolbox&amp;diff=4256</id>
		<title>DE4A Service Interoperability Solutions Toolbox</title>
		<link rel="alternate" type="text/html" href="https://wiki.de4a.eu/index.php?title=DE4A_Service_Interoperability_Solutions_Toolbox&amp;diff=4256"/>
		<updated>2022-02-01T09:24:24Z</updated>

		<summary type="html">&lt;p&gt;Ictu mavi.cristache: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;lt;imagemap&amp;gt;&lt;br /&gt;
File:Service_Interoperability_Solutions_Toolbox.png|&lt;br /&gt;
&lt;br /&gt;
rect 455 124 541 590 [[https://wiki.de4a.eu/index.php/Intermediation_Pattern|Intermediation pattern]]&lt;br /&gt;
rect 558 103 651 562 [[https://wiki.de4a.eu/index.php/User-supported_Intermediation_Pattern|USI pattern]]&lt;br /&gt;
rect 672 78 750 548 [[https://wiki.de4a.eu/index.php/Verifiable_Credentials_Pattern|VC pattern]]&lt;br /&gt;
rect 765 57 853 523 [[https://wiki.de4a.eu/index.php/Subscription_and_Notification_Pattern|S&amp;amp;N pattern]]&lt;br /&gt;
rect 868 50 960 516 [[https://wiki.de4a.eu/index.php/Lookup_Pattern|LKP pattern]]&lt;br /&gt;
rect 366 36 441 619 [[https://wiki.de4a.eu/index.php/Reference_Architecture|Reference Architecture]]&lt;br /&gt;
rect 992 57 2159 587 [[https://wiki.de4a.eu/index.php/Application_Services|Application Services]]&lt;br /&gt;
rect 324 640 2571 697 [[https://wiki.de4a.eu/index.php/Pilots|DE4A Pilots]]&lt;br /&gt;
rect 651 743 1209 992 [[https://wiki.de4a.eu/index.php/DE4A_Semantic_interoperability|Semantic solutions]]&lt;br /&gt;
rect 1287 740 1835 989 [[https://wiki.de4a.eu/index.php/Category:WP5|Common Components]]&lt;br /&gt;
rect 1920 747 2468 992 [[https://wiki.de4a.eu/index.php/Building_Blocks|Building Blocks]]&lt;br /&gt;
&lt;br /&gt;
desc bottom-left&lt;br /&gt;
&amp;lt;/imagemap&amp;gt;&lt;br /&gt;
&lt;br /&gt;
__NOTOC__&lt;br /&gt;
&lt;br /&gt;
This toolbox is the central, long-term deliverable of the DE4A Architecture work package (WP2) and takes the form of a structured, online architecture repository that extends from the content of the Architecture Framework and prior work of e-SENS. The toolbox includes (pointers to) prior work in CEF, ISA, ISA&amp;lt;sup&amp;gt;2&amp;lt;/sup&amp;gt; and prior LSPs. It includes new DE4A common components and implementation method and Pilot insights. &lt;br /&gt;
[[File:Service Interoperability Solutions Toolbox.png|center|frameless|900x900px]] &lt;br /&gt;
&lt;br /&gt;
== [[Pilots]] ==&lt;br /&gt;
DE4A includes three cross-border and cross-domain [[Pilots]] - &amp;lt;span style=&amp;quot;background:#00FF00&amp;quot;&amp;gt;[[Studying Abroad Pilot]]&amp;lt;/span&amp;gt;, &amp;lt;span style=&amp;quot;background:#FFFF00&amp;quot;&amp;gt;[[Doing Business Abroad Pilot]]&amp;lt;/span&amp;gt;, and &amp;lt;span style=&amp;quot;background:#00FFFF&amp;quot;&amp;gt;[[Moving Abroad Pilot]]&amp;lt;/span&amp;gt; -, comprising different functional use cases focused on different high-impact and viable administrative procedures, and aimed to realize tangible benefits in fully operational environments to real users (citizens, students, business persons and public servants). The Pilots are delivered by a separate, agile, multi-disciplinary, inter-member state teams of experts. The focus of these teams is on iterative system integration and configuration, hence on making existing building blocks and solutions work together in real life cases.&lt;br /&gt;
&lt;br /&gt;
== [[Reference Architecture|Reference Architecture]] ==&lt;br /&gt;
DE4A developed a multi-pattern architecture for eGovernment interoperability with a focus on digital-by-default procedures for citizens and businesses and the full implementation of the Once-Only Principle. It provides guidance to the DE4A pilots and to  projects seeking to implement cross-border once-only enabled eProcedures. &lt;br /&gt;
&lt;br /&gt;
== [[Library of components and  building blocks]] ==&lt;br /&gt;
&lt;br /&gt;
This section contains the collection components and candidate Building Blocks. The classification of this library follows the DE4A [[Reference Architecture]], starting on the highest level of architecture components: the Application Collaborations. These Application collaborations are aggregations of Application components, Data objects and Interfaces.  &lt;br /&gt;
&lt;br /&gt;
The reference architecture at conceptional/functional level is completed with a catalogue of candidate building blocks mapped to required Application Services that they are intended to deliver in the context of each pilot.  &lt;br /&gt;
&lt;br /&gt;
==DE4A Solutions==&lt;br /&gt;
The DE4A Solutions are split in Semantic Interoperability Solutions and Common Components. The first deals with semantic specifications, the second with SW components. There is also a link related to development and testing activities. &lt;br /&gt;
&lt;br /&gt;
[[DE4A Semantic interoperability|Semantic Interoperability Solutions]]&lt;br /&gt;
&lt;br /&gt;
[[WP5|Common Components]]&lt;br /&gt;
&lt;br /&gt;
[[DE4A Development and Testing]]&lt;br /&gt;
&lt;br /&gt;
== Legal and ethical support ==&lt;br /&gt;
DE4A also provides a [[Legal and ethical analysis]]. &lt;br /&gt;
&lt;br /&gt;
(Inputs and suggestions can be provided on the subpage)&lt;br /&gt;
&lt;br /&gt;
[[Category:wip]]&lt;/div&gt;</summary>
		<author><name>Ictu mavi.cristache</name></author>
	</entry>
	<entry>
		<id>https://wiki.de4a.eu/index.php?title=DE4A_Service_Interoperability_Solutions_Toolbox&amp;diff=4151</id>
		<title>DE4A Service Interoperability Solutions Toolbox</title>
		<link rel="alternate" type="text/html" href="https://wiki.de4a.eu/index.php?title=DE4A_Service_Interoperability_Solutions_Toolbox&amp;diff=4151"/>
		<updated>2022-01-26T13:55:14Z</updated>

		<summary type="html">&lt;p&gt;Ictu mavi.cristache: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;__NOTOC__&lt;br /&gt;
&lt;br /&gt;
This toolbox is the central, long-term deliverable of the DE4A Architecture work package (WP2) and takes the form of a structured, online architecture repository that extends from the content of the Architecture Framework and prior work of e-SENS. The toolbox includes (pointers to) prior work in CEF, ISA, ISA&amp;lt;sup&amp;gt;2&amp;lt;/sup&amp;gt; and prior LSPs. It includes new DE4A common components and implementation method and Pilot insights. &lt;br /&gt;
[[File:Service Interoperability Solutions Toolbox.png|center|frameless|900x900px]] &lt;br /&gt;
&lt;br /&gt;
== [[Pilots]] ==&lt;br /&gt;
DE4A includes three cross-border and cross-domain [[Pilots]] - &amp;lt;span style=&amp;quot;background:#00FF00&amp;quot;&amp;gt;[[Studying Abroad Pilot]]&amp;lt;/span&amp;gt;, &amp;lt;span style=&amp;quot;background:#FFFF00&amp;quot;&amp;gt;[[Doing Business Abroad Pilot]]&amp;lt;/span&amp;gt;, and &amp;lt;span style=&amp;quot;background:#00FFFF&amp;quot;&amp;gt;[[Moving Abroad Pilot]]&amp;lt;/span&amp;gt; -, comprising different functional use cases focused on different high-impact and viable administrative procedures, and aimed to realize tangible benefits in fully operational environments to real users (citizens, students, business persons and public servants). The Pilots are delivered by a separate, agile, multi-disciplinary, inter-member state teams of experts. The focus of these teams is on iterative system integration and configuration, hence on making existing building blocks and solutions work together in real life cases.&lt;br /&gt;
&lt;br /&gt;
== [[Reference Architecture|Reference Architecture]] ==&lt;br /&gt;
DE4A develops a multi-pattern architecture for eGovernment interoperability with a focus on digital-by default procedures for citizens and businesses and the full implementation of the Once-Only Principle. The DE4A Architecture Framework defines five architecture [[Time Horizons]] staring from the pre-SDG baseline (t=0, ~2019) and reaching to a long-term vision (t=4, ~2030+) in order to place different developments in context. More detail on the Architecture Framework is available in the public deliverable [https://b0b3923b-028b-4cc4-aa23-7b874a2ae593.filesusr.com/ugd/2844e6_ec9fb88703ef431c8a55c63b294fb2cd.pdf D2.1 Architecture Framework].&lt;br /&gt;
&lt;br /&gt;
The development of the DE4A [[Reference Architecture]] started in the context of [https://wiki.de4a.eu/images/f/f4/DE4A_D2.4_Project_Start_Architecture_-_v2.3.pdf D2.4 Project Start Architecture (PSA) - First iteration]  and recognizes three distinct Reference Interaction Patterns:&lt;br /&gt;
*[[Intermediation Pattern]]&lt;br /&gt;
*[[User-supported Intermediation Pattern]]&lt;br /&gt;
*[[Verifiable Credentials Pattern]]&lt;br /&gt;
The forthcoming D2.5 Project Start Architecture (PSA) - Second iteration is introducing two additional Reference Interaction Pattern: &lt;br /&gt;
&lt;br /&gt;
* [[Subscription and Notification Pattern]]&lt;br /&gt;
* [[Lookup Pattern]]&lt;br /&gt;
The [[Architecture Log]] keeps track of deviations from DE4A principles and the reference architecture in general and also records the implications.&lt;br /&gt;
&lt;br /&gt;
== [[Library of components and  building blocks]] ==&lt;br /&gt;
&lt;br /&gt;
This section contains the collection components and candidate Building Blocks. The classification of this library follows the DE4A [[Reference Architecture]], starting on the highest level of architecture components: the Application Collaborations. These Application collaborations are aggregations of Application components, Data objects and Interfaces.  &lt;br /&gt;
&lt;br /&gt;
The reference architecture at conceptional/functional level is completed with a catalogue of candidate building blocks mapped to required Application Services that they are intended to deliver in the context of each pilot.  &lt;br /&gt;
&lt;br /&gt;
==DE4A Solutions==&lt;br /&gt;
The DE4A Solutions are split in Semantic Interoperability Solutions and Common Components. The first deals with semantic specifications, the second with SW components. There is also a link related to development and testing activities. &lt;br /&gt;
&lt;br /&gt;
[[DE4A Semantic interoperability|Semantic Interoperability Solutions]]&lt;br /&gt;
&lt;br /&gt;
[[WP5|Common Components]]&lt;br /&gt;
&lt;br /&gt;
[[DE4A Development and Testing]]&lt;br /&gt;
&lt;br /&gt;
== Legal and ethical support ==&lt;br /&gt;
DE4A also provides a [[Legal and ethical analysis]]. &lt;br /&gt;
&lt;br /&gt;
(Inputs and suggestions can be provided on the subpage)&lt;br /&gt;
&lt;br /&gt;
[[Category:wip]]&lt;/div&gt;</summary>
		<author><name>Ictu mavi.cristache</name></author>
	</entry>
	<entry>
		<id>https://wiki.de4a.eu/index.php?title=File:Service_Interoperability_Solutions_Toolbox.png&amp;diff=4149</id>
		<title>File:Service Interoperability Solutions Toolbox.png</title>
		<link rel="alternate" type="text/html" href="https://wiki.de4a.eu/index.php?title=File:Service_Interoperability_Solutions_Toolbox.png&amp;diff=4149"/>
		<updated>2022-01-26T13:54:00Z</updated>

		<summary type="html">&lt;p&gt;Ictu mavi.cristache: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Service Interoperability Solutions Toolbox&lt;/div&gt;</summary>
		<author><name>Ictu mavi.cristache</name></author>
	</entry>
	<entry>
		<id>https://wiki.de4a.eu/index.php?title=MediaWiki:Sidebar&amp;diff=4142</id>
		<title>MediaWiki:Sidebar</title>
		<link rel="alternate" type="text/html" href="https://wiki.de4a.eu/index.php?title=MediaWiki:Sidebar&amp;diff=4142"/>
		<updated>2022-01-26T13:38:20Z</updated>

		<summary type="html">&lt;p&gt;Ictu mavi.cristache: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;* navigation&lt;br /&gt;
** Disclaimer|Disclaimer&lt;br /&gt;
** mainpage|mainpage-description&lt;br /&gt;
** recentchanges-url|recentchanges&lt;br /&gt;
** randompage-url|randompage&lt;br /&gt;
** helppage|help-mediawiki&lt;br /&gt;
&lt;br /&gt;
*DE4A Documentation&lt;br /&gt;
**Pilots|Pilots&lt;br /&gt;
**Reference Architecture|Reference Architecture&lt;br /&gt;
**Library of components and building blocks|Components and building blocks&lt;br /&gt;
&lt;br /&gt;
*Other&lt;br /&gt;
**Getting started|Getting started&lt;br /&gt;
**Special:ListFiles|Files&lt;br /&gt;
**Glossary|Glossary&lt;br /&gt;
&lt;br /&gt;
* SEARCH&lt;br /&gt;
* TOOLBOX&lt;br /&gt;
* LANGUAGES&lt;/div&gt;</summary>
		<author><name>Ictu mavi.cristache</name></author>
	</entry>
	<entry>
		<id>https://wiki.de4a.eu/index.php?title=Legal_disclaimer_and_copyrights&amp;diff=4141</id>
		<title>Legal disclaimer and copyrights</title>
		<link rel="alternate" type="text/html" href="https://wiki.de4a.eu/index.php?title=Legal_disclaimer_and_copyrights&amp;diff=4141"/>
		<updated>2022-01-26T13:37:11Z</updated>

		<summary type="html">&lt;p&gt;Ictu mavi.cristache: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This DE4A wiki is created, hosted and maintained by and on behalf of the members of the DE4A consortium (see [https://www.de4a.eu/consortium https://www.de4a.eu/consortium]). All contents are provided in good faith by persons supporting this consortium, with the common objective of furthering the progress of the DE4A project.&lt;br /&gt;
 &lt;br /&gt;
Anyone with appropriate credentials may choose to add or edit contents of the DE4A wiki. Any contributions to the content remain owned by the respective contributor(s), but by submitting any contents, you explicitly authorise the DE4A consortium to publish and disseminate the contents via the wiki. Furthermore, you authorise the members of the DE4A consortium to use your contents for any purposes (including usage outside of this wiki) that would benefit the execution of the DE4A project. Each contributor should apply reasonable care to verify that their contributions are likely to contribute to the progress of the DE4A project, given the expertise and knowledge of the contributor and the state of the project. In case of doubts on this point, the contributor should take care to communicate any applicable constraints or reservations in the contribution. Each contributor is responsible for ensuring that their individual contributions are lawful, including but not limited to ensuring that contributions do not violate any third party intellectual property rights.&lt;br /&gt;
 &lt;br /&gt;
Irrespective of the above, contents are provided purely on an ‘as is’ basis, without any guarantees of accuracy, completeness or usability for any particular purpose. Contents do not necessarily reflect a consensus or a shared position of the DE4A consortium as a whole, nor even of any individual member. Anyone who decides to rely on the contents of the DE4A wiki for any reason or purpose should apply their own diligence, and assumes full and exclusive responsibility and liability for any consequences of their reliance on the contents. No assurances are provided with respect to the contents, neither explicitly nor implied.&lt;/div&gt;</summary>
		<author><name>Ictu mavi.cristache</name></author>
	</entry>
	<entry>
		<id>https://wiki.de4a.eu/index.php?title=Legal_disclaimer_and_copyrights&amp;diff=4140</id>
		<title>Legal disclaimer and copyrights</title>
		<link rel="alternate" type="text/html" href="https://wiki.de4a.eu/index.php?title=Legal_disclaimer_and_copyrights&amp;diff=4140"/>
		<updated>2022-01-26T13:36:54Z</updated>

		<summary type="html">&lt;p&gt;Ictu mavi.cristache: Created page with &amp;quot;Disclaimer  This DE4A wiki is created, hosted and maintained by and on behalf of the members of the DE4A consortium (see [https://www.de4a.eu/consortium https://www.de4a.eu/co...&amp;quot;&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Disclaimer&lt;br /&gt;
&lt;br /&gt;
This DE4A wiki is created, hosted and maintained by and on behalf of the members of the DE4A consortium (see [https://www.de4a.eu/consortium https://www.de4a.eu/consortium]). All contents are provided in good faith by persons supporting this consortium, with the common objective of furthering the progress of the DE4A project.&lt;br /&gt;
 &lt;br /&gt;
Anyone with appropriate credentials may choose to add or edit contents of the DE4A wiki. Any contributions to the content remain owned by the respective contributor(s), but by submitting any contents, you explicitly authorise the DE4A consortium to publish and disseminate the contents via the wiki. Furthermore, you authorise the members of the DE4A consortium to use your contents for any purposes (including usage outside of this wiki) that would benefit the execution of the DE4A project. Each contributor should apply reasonable care to verify that their contributions are likely to contribute to the progress of the DE4A project, given the expertise and knowledge of the contributor and the state of the project. In case of doubts on this point, the contributor should take care to communicate any applicable constraints or reservations in the contribution. Each contributor is responsible for ensuring that their individual contributions are lawful, including but not limited to ensuring that contributions do not violate any third party intellectual property rights.&lt;br /&gt;
 &lt;br /&gt;
Irrespective of the above, contents are provided purely on an ‘as is’ basis, without any guarantees of accuracy, completeness or usability for any particular purpose. Contents do not necessarily reflect a consensus or a shared position of the DE4A consortium as a whole, nor even of any individual member. Anyone who decides to rely on the contents of the DE4A wiki for any reason or purpose should apply their own diligence, and assumes full and exclusive responsibility and liability for any consequences of their reliance on the contents. No assurances are provided with respect to the contents, neither explicitly nor implied.&lt;/div&gt;</summary>
		<author><name>Ictu mavi.cristache</name></author>
	</entry>
	<entry>
		<id>https://wiki.de4a.eu/index.php?title=DE4A_Service_Interoperability_Solutions_Toolbox&amp;diff=4139</id>
		<title>DE4A Service Interoperability Solutions Toolbox</title>
		<link rel="alternate" type="text/html" href="https://wiki.de4a.eu/index.php?title=DE4A_Service_Interoperability_Solutions_Toolbox&amp;diff=4139"/>
		<updated>2022-01-26T13:35:36Z</updated>

		<summary type="html">&lt;p&gt;Ictu mavi.cristache: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;__NOTOC__&lt;br /&gt;
&lt;br /&gt;
This toolbox is the central, long-term deliverable of the DE4A Architecture work package (WP2) and takes the form of a structured, online architecture repository that extends from the content of the Architecture Framework and prior work of e-SENS. The toolbox includes (pointers to) prior work in CEF, ISA, ISA&amp;lt;sup&amp;gt;2&amp;lt;/sup&amp;gt; and prior LSPs. It includes new DE4A common components and implementation method and Pilot insights. &lt;br /&gt;
&lt;br /&gt;
== [[Pilots]] ==&lt;br /&gt;
DE4A includes three cross-border and cross-domain [[Pilots]] - &amp;lt;span style=&amp;quot;background:#00FF00&amp;quot;&amp;gt;[[Studying Abroad Pilot]]&amp;lt;/span&amp;gt;, &amp;lt;span style=&amp;quot;background:#FFFF00&amp;quot;&amp;gt;[[Doing Business Abroad Pilot]]&amp;lt;/span&amp;gt;, and &amp;lt;span style=&amp;quot;background:#00FFFF&amp;quot;&amp;gt;[[Moving Abroad Pilot]]&amp;lt;/span&amp;gt; -, comprising different functional use cases focused on different high-impact and viable administrative procedures, and aimed to realize tangible benefits in fully operational environments to real users (citizens, students, business persons and public servants). The Pilots are delivered by a separate, agile, multi-disciplinary, inter-member state teams of experts. The focus of these teams is on iterative system integration and configuration, hence on making existing building blocks and solutions work together in real life cases.&lt;br /&gt;
&lt;br /&gt;
== [[Reference Architecture|Reference Architecture]] ==&lt;br /&gt;
DE4A develops a multi-pattern architecture for eGovernment interoperability with a focus on digital-by default procedures for citizens and businesses and the full implementation of the Once-Only Principle. The DE4A Architecture Framework defines five architecture [[Time Horizons]] staring from the pre-SDG baseline (t=0, ~2019) and reaching to a long-term vision (t=4, ~2030+) in order to place different developments in context. More detail on the Architecture Framework is available in the public deliverable [https://b0b3923b-028b-4cc4-aa23-7b874a2ae593.filesusr.com/ugd/2844e6_ec9fb88703ef431c8a55c63b294fb2cd.pdf D2.1 Architecture Framework].&lt;br /&gt;
&lt;br /&gt;
The development of the DE4A [[Reference Architecture]] started in the context of [https://wiki.de4a.eu/images/f/f4/DE4A_D2.4_Project_Start_Architecture_-_v2.3.pdf D2.4 Project Start Architecture (PSA) - First iteration]  and recognizes three distinct Reference Interaction Patterns:&lt;br /&gt;
*[[Intermediation Pattern]]&lt;br /&gt;
*[[User-supported Intermediation Pattern]]&lt;br /&gt;
*[[Verifiable Credentials Pattern]]&lt;br /&gt;
The forthcoming D2.5 Project Start Architecture (PSA) - Second iteration is introducing two additional Reference Interaction Pattern: &lt;br /&gt;
&lt;br /&gt;
* [[Subscription and Notification Pattern]]&lt;br /&gt;
* [[Lookup Pattern]]&lt;br /&gt;
The [[Architecture Log]] keeps track of deviations from DE4A principles and the reference architecture in general and also records the implications.&lt;br /&gt;
&lt;br /&gt;
== [[Library of components and  building blocks]] ==&lt;br /&gt;
&lt;br /&gt;
This section contains the collection of technical and semantic common components and candidate Building Blocks that are relevant for eGovernment interoperability in general and digital-by-default procedures and the Once-only Principle in particular. The classification of this library follows the DE4A [[Reference Architecture]], starting on the highest level of architecture components: the Application collaborations. These Application collaborations are aggregations of Application components, Data objects and Interfaces. You will find on each Application component pages a list of relevant DE4A common components, candidate Building Blocks (e.g. CEF) and memberstate solutions that jointly or alternatively realize that Application component. &lt;br /&gt;
&lt;br /&gt;
==DE4A Solutions==&lt;br /&gt;
The DE4A Solutions are split in Semantic Interoperability Solutions and Common Components. The first deals with semantic specifications, the second with SW components. There is also a link related to development and testing activities. &lt;br /&gt;
&lt;br /&gt;
[[DE4A Semantic interoperability|Semantic Interoperability Solutions]]&lt;br /&gt;
&lt;br /&gt;
[[WP5|Common Components]]&lt;br /&gt;
&lt;br /&gt;
[[DE4A Development and Testing]]&lt;br /&gt;
&lt;br /&gt;
== Legal and ethical support ==&lt;br /&gt;
DE4A also provides a [[Legal and ethical analysis]]. &lt;br /&gt;
&lt;br /&gt;
(Inputs and suggestions can be provided on the subpage)&lt;br /&gt;
&lt;br /&gt;
[[Category:wip]]&lt;/div&gt;</summary>
		<author><name>Ictu mavi.cristache</name></author>
	</entry>
	<entry>
		<id>https://wiki.de4a.eu/index.php?title=DE4A_Service_Interoperability_Solutions_Toolbox&amp;diff=4138</id>
		<title>DE4A Service Interoperability Solutions Toolbox</title>
		<link rel="alternate" type="text/html" href="https://wiki.de4a.eu/index.php?title=DE4A_Service_Interoperability_Solutions_Toolbox&amp;diff=4138"/>
		<updated>2022-01-26T13:34:59Z</updated>

		<summary type="html">&lt;p&gt;Ictu mavi.cristache: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;__NOTOC__&lt;br /&gt;
&lt;br /&gt;
This toolbox is the central, long-term deliverable of the DE4A Architecture work package (WP2) and takes the form of a structured, online architecture repository that extends from the content of the Architecture Framework and prior work of e-SENS. The toolbox includes (pointers to) prior work in CEF, ISA, ISA&amp;lt;sup&amp;gt;2&amp;lt;/sup&amp;gt; and prior LSPs. It includes new DE4A common components and implementation method and Pilot insights. &lt;br /&gt;
&lt;br /&gt;
== [[Pilots]] ==&lt;br /&gt;
DE4A includes three cross-border and cross-domain [[Pilots]] - &amp;lt;span style=&amp;quot;background:#00FF00&amp;quot;&amp;gt;[[Studying Abroad Pilot]]&amp;lt;/span&amp;gt;, &amp;lt;span style=&amp;quot;background:#FFFF00&amp;quot;&amp;gt;[[Doing Business Abroad Pilot]]&amp;lt;/span&amp;gt;, and &amp;lt;span style=&amp;quot;background:#00FFFF&amp;quot;&amp;gt;[[Moving Abroad Pilot]]&amp;lt;/span&amp;gt; -, comprising different functional use cases focused on different high-impact and viable administrative procedures, and aimed to realize tangible benefits in fully operational environments to real users (citizens, students, business persons and public servants). The Pilots are delivered by a separate, agile, multi-disciplinary, inter-member state teams of experts. The focus of these teams is on iterative system integration and configuration, hence on making existing building blocks and solutions work together in real life cases.&lt;br /&gt;
&lt;br /&gt;
== [[Reference Architecture|Reference Architecture]] ==&lt;br /&gt;
DE4A develops a multi-pattern architecture for eGovernment interoperability with a focus on digital-by default procedures for citizens and businesses and the full implementation of the Once-Only Principle. The DE4A Architecture Framework defines five architecture [[Time Horizons]] staring from the pre-SDG baseline (t=0, ~2019) and reaching to a long-term vision (t=4, ~2030+) in order to place different developments in context. More detail on the Architecture Framework is available in the public deliverable [https://b0b3923b-028b-4cc4-aa23-7b874a2ae593.filesusr.com/ugd/2844e6_ec9fb88703ef431c8a55c63b294fb2cd.pdf D2.1 Architecture Framework].&lt;br /&gt;
&lt;br /&gt;
The development of the DE4A [[Reference Architecture]] started in the context of [https://wiki.de4a.eu/images/f/f4/DE4A_D2.4_Project_Start_Architecture_-_v2.3.pdf D2.4 Project Start Architecture (PSA) - First iteration]  and recognizes three distinct Reference Interaction Patterns:&lt;br /&gt;
*[[Intermediation Pattern]]&lt;br /&gt;
*[[User-supported Intermediation Pattern]]&lt;br /&gt;
*[[Verifiable Credentials Pattern]]&lt;br /&gt;
The forthcoming D2.5 Project Start Architecture (PSA) - Second iteration is introducing two additional Reference Interaction Pattern: &lt;br /&gt;
&lt;br /&gt;
* [[Subscription and Notification Pattern]]&lt;br /&gt;
* [[Lookup Pattern]]&lt;br /&gt;
The [[Architecture Log]] keeps track of deviations from DE4A principles and the reference architecture in general and also records the implications.&lt;br /&gt;
&lt;br /&gt;
== [[Library of components and  building blocks]] ==&lt;br /&gt;
&lt;br /&gt;
This section contains the collection of technical and semantic common components and candidate Building Blocks that are relevant for eGovernment interoperability in general and digital-by-default procedures and the Once-only Principle in particular. The classification of this library follows the DE4A [[Reference Architecture]], starting on the highest level of architecture components: the Application collaborations. These Application collaborations are aggregations of Application components, Data objects and Interfaces. You will find on each Application component pages a list of relevant DE4A common components, candidate Building Blocks (e.g. CEF) and memberstate solutions that jointly or alternatively realize that Application component. &lt;br /&gt;
&lt;br /&gt;
==DE4A Solutions==&lt;br /&gt;
The DE4A Solutions are split in Semantic Interoperability Solutions and Common Components. The first deals with semantic specifications, the second with SW components. There is also a link related to development and testing activities. &lt;br /&gt;
&lt;br /&gt;
[[DE4A Semantic interoperability|Semantic Interoperability Solutions]]&lt;br /&gt;
&lt;br /&gt;
[[WP5|Common Components]]&lt;br /&gt;
&lt;br /&gt;
[[DE4A Development and Testing]]&lt;br /&gt;
&lt;br /&gt;
== Legal and ethical support ==&lt;br /&gt;
DE4A also provides a [[Legal and ethical analysis]]. &lt;br /&gt;
&lt;br /&gt;
(Inputs and suggestions can be provided on the subpage)&lt;br /&gt;
&lt;br /&gt;
'''''Disclaimer'''''&lt;br /&gt;
&lt;br /&gt;
''&amp;lt;small&amp;gt;This DE4A wiki is created, hosted and maintained by and on behalf of the members of the DE4A consortium (see [https://www.de4a.eu/consortium https://www.de4a.eu/consortium]). All contents are provided in good faith by persons supporting this consortium, with the common objective of furthering the progress of the DE4A project.&amp;lt;/small&amp;gt;'' &lt;br /&gt;
 &lt;br /&gt;
''&amp;lt;small&amp;gt;Anyone with appropriate credentials may choose to add or edit contents of the DE4A wiki. Any contributions to the content remain owned by the respective contributor(s), but by submitting any contents, you explicitly authorise the DE4A consortium to publish and disseminate the contents via the wiki. Furthermore, you authorise the members of the DE4A consortium to use your contents for any purposes (including usage outside of this wiki) that would benefit the execution of the DE4A project. Each contributor should apply reasonable care to verify that their contributions are likely to contribute to the progress of the DE4A project, given the expertise and knowledge of the contributor and the state of the project. In case of doubts on this point, the contributor should take care to communicate any applicable constraints or reservations in the contribution. Each contributor is responsible for ensuring that their individual contributions are lawful, including but not limited to ensuring that contributions do not violate any third party intellectual property rights.&amp;lt;/small&amp;gt;'' &lt;br /&gt;
 &lt;br /&gt;
''&amp;lt;small&amp;gt;Irrespective of the above, contents are provided purely on an ‘as is’ basis, without any guarantees of accuracy, completeness or usability for any particular purpose. Contents do not necessarily reflect a consensus or a shared position of the DE4A consortium as a whole, nor even of any individual member. Anyone who decides to rely on the contents of the DE4A wiki for any reason or purpose should apply their own diligence, and assumes full and exclusive responsibility and liability for any consequences of their reliance on the contents. No assurances are provided with respect to the contents, neither explicitly nor implied.&amp;lt;/small&amp;gt;'' &lt;br /&gt;
&lt;br /&gt;
[[Category:wip]]&lt;/div&gt;</summary>
		<author><name>Ictu mavi.cristache</name></author>
	</entry>
	<entry>
		<id>https://wiki.de4a.eu/index.php?title=MediaWiki:Sidebar&amp;diff=4109</id>
		<title>MediaWiki:Sidebar</title>
		<link rel="alternate" type="text/html" href="https://wiki.de4a.eu/index.php?title=MediaWiki:Sidebar&amp;diff=4109"/>
		<updated>2022-01-24T16:43:04Z</updated>

		<summary type="html">&lt;p&gt;Ictu mavi.cristache: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;* navigation&lt;br /&gt;
** mainpage|mainpage-description&lt;br /&gt;
** recentchanges-url|recentchanges&lt;br /&gt;
** randompage-url|randompage&lt;br /&gt;
** helppage|help-mediawiki&lt;br /&gt;
&lt;br /&gt;
*DE4A Documentation&lt;br /&gt;
**Pilots|Pilots&lt;br /&gt;
**Reference Architecture|Reference Architecture&lt;br /&gt;
**Library of components and building blocks|Components and building blocks&lt;br /&gt;
&lt;br /&gt;
*Other&lt;br /&gt;
**Getting started|Getting started&lt;br /&gt;
**Special:ListFiles|Files&lt;br /&gt;
**Glossary|Glossary&lt;br /&gt;
&lt;br /&gt;
* SEARCH&lt;br /&gt;
* TOOLBOX&lt;br /&gt;
* LANGUAGES&lt;/div&gt;</summary>
		<author><name>Ictu mavi.cristache</name></author>
	</entry>
	<entry>
		<id>https://wiki.de4a.eu/index.php?title=Glossary&amp;diff=4100</id>
		<title>Glossary</title>
		<link rel="alternate" type="text/html" href="https://wiki.de4a.eu/index.php?title=Glossary&amp;diff=4100"/>
		<updated>2022-01-24T12:41:58Z</updated>

		<summary type="html">&lt;p&gt;Ictu mavi.cristache: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;__NOTOC__&lt;br /&gt;
&lt;br /&gt;
== 0-9 ==&lt;br /&gt;
...&lt;br /&gt;
&lt;br /&gt;
== A ==&lt;br /&gt;
&lt;br /&gt;
=== ABB / Architecture Building Block ===&lt;br /&gt;
...&lt;br /&gt;
&lt;br /&gt;
=== ADM / Architecture Development Method ===&lt;br /&gt;
...&lt;br /&gt;
&lt;br /&gt;
== B ==&lt;br /&gt;
&lt;br /&gt;
=== BB / Building Block ===&lt;br /&gt;
...&lt;br /&gt;
&lt;br /&gt;
=== BPMN / Business Process Model and Notation ===&lt;br /&gt;
...&lt;br /&gt;
&lt;br /&gt;
=== BPR / Business Process Reengineering ===&lt;br /&gt;
...&lt;br /&gt;
&lt;br /&gt;
=== BRIS / Business Register Interconnection System ===&lt;br /&gt;
...&lt;br /&gt;
&lt;br /&gt;
== C ==&lt;br /&gt;
&lt;br /&gt;
=== CEF / Connecting Europe Facility ===&lt;br /&gt;
...&lt;br /&gt;
&lt;br /&gt;
=== CFREU / Charter of Fundamental Rights of the European Union (2012/C 326/02) ===&lt;br /&gt;
...&lt;br /&gt;
&lt;br /&gt;
=== CPSV-AP / Core Public Service Vocabulary Application Profile ===&lt;br /&gt;
...&lt;br /&gt;
&lt;br /&gt;
== D ==&lt;br /&gt;
&lt;br /&gt;
=== DC / Data consumer ===&lt;br /&gt;
...&lt;br /&gt;
&lt;br /&gt;
=== DCAT / Data Cataloge Vocabulary ===&lt;br /&gt;
...&lt;br /&gt;
&lt;br /&gt;
=== DE4A / Digital Europe for All (this project) ===&lt;br /&gt;
...&lt;br /&gt;
&lt;br /&gt;
=== DEP / Digital Europe Programme ===&lt;br /&gt;
...&lt;br /&gt;
&lt;br /&gt;
=== DP / Data provider ===&lt;br /&gt;
...&lt;br /&gt;
&lt;br /&gt;
=== DSM / Digital Single Market ===&lt;br /&gt;
...&lt;br /&gt;
&lt;br /&gt;
== E ==&lt;br /&gt;
&lt;br /&gt;
=== EAI / Enterprise Application Integration ===&lt;br /&gt;
...&lt;br /&gt;
&lt;br /&gt;
=== EC / European Commission ===&lt;br /&gt;
...&lt;br /&gt;
&lt;br /&gt;
=== ECRIS / European Criminal Records Information Exchange System ===&lt;br /&gt;
...&lt;br /&gt;
&lt;br /&gt;
=== EESSI / Electronic Exchange of Social Security Information ===&lt;br /&gt;
...&lt;br /&gt;
&lt;br /&gt;
=== EIF / European Interoperability Framework ===&lt;br /&gt;
...&lt;br /&gt;
&lt;br /&gt;
=== ESL / DE4A Evidence Service Locator ===&lt;br /&gt;
...&lt;br /&gt;
&lt;br /&gt;
=== EIRA / European Interoperability Reference Architecture ===&lt;br /&gt;
...&lt;br /&gt;
&lt;br /&gt;
=== EUCARIS / the European car and driving licence information system ===&lt;br /&gt;
...&lt;br /&gt;
&lt;br /&gt;
=== EUGIP / European Government Interoperability Platform ===&lt;br /&gt;
...&lt;br /&gt;
&lt;br /&gt;
== F ==&lt;br /&gt;
...&lt;br /&gt;
&lt;br /&gt;
== G ==&lt;br /&gt;
&lt;br /&gt;
=== GDPR / General Data Protection Regulation ===&lt;br /&gt;
...&lt;br /&gt;
&lt;br /&gt;
== H ==&lt;br /&gt;
...&lt;br /&gt;
&lt;br /&gt;
== I ==&lt;br /&gt;
&lt;br /&gt;
=== IAL / DE4A Issuing Authority Locator ===&lt;br /&gt;
...&lt;br /&gt;
&lt;br /&gt;
=== IDK / DE4A Information Desk (IAL+ESL+MOR) ===&lt;br /&gt;
...&lt;br /&gt;
&lt;br /&gt;
=== IEM / DEA4 Information Exchange Model ===&lt;br /&gt;
...&lt;br /&gt;
&lt;br /&gt;
=== ISA2 / Interoperability solutions for public administrations, businesses and citizens ===&lt;br /&gt;
...&lt;br /&gt;
&lt;br /&gt;
== J ==&lt;br /&gt;
...&lt;br /&gt;
&lt;br /&gt;
== K ==&lt;br /&gt;
...&lt;br /&gt;
&lt;br /&gt;
== L ==&lt;br /&gt;
&lt;br /&gt;
=== LSP / Large Scale Pilot ===&lt;br /&gt;
...&lt;br /&gt;
&lt;br /&gt;
== M ==&lt;br /&gt;
&lt;br /&gt;
=== MOR / DE4A Multilingual Ontology Repository ===&lt;br /&gt;
...&lt;br /&gt;
&lt;br /&gt;
=== MS / Member State ===&lt;br /&gt;
...&lt;br /&gt;
&lt;br /&gt;
== N ==&lt;br /&gt;
&lt;br /&gt;
=== N/A / Not Applicable ===&lt;br /&gt;
...&lt;br /&gt;
&lt;br /&gt;
=== NRT / Near Real Time ===&lt;br /&gt;
...&lt;br /&gt;
&lt;br /&gt;
== O ==&lt;br /&gt;
&lt;br /&gt;
=== OOP / Once Only Principle ===&lt;br /&gt;
...&lt;br /&gt;
&lt;br /&gt;
=== OSI / Open Systems Interconnection model (OSI model) ===&lt;br /&gt;
...&lt;br /&gt;
&lt;br /&gt;
== P ==&lt;br /&gt;
&lt;br /&gt;
=== PSA / Project Start Architecture ===&lt;br /&gt;
...&lt;br /&gt;
&lt;br /&gt;
== Q ==&lt;br /&gt;
...&lt;br /&gt;
&lt;br /&gt;
== R ==&lt;br /&gt;
...&lt;br /&gt;
&lt;br /&gt;
== S ==&lt;br /&gt;
&lt;br /&gt;
=== SBB / Solution Building Block ===&lt;br /&gt;
...&lt;br /&gt;
&lt;br /&gt;
=== SDG / Single Digital Gateway ===&lt;br /&gt;
...&lt;br /&gt;
&lt;br /&gt;
=== SDGR / Single Digital Gateway Regulation (REGULATION (EU) 2018/1724) ===&lt;br /&gt;
...&lt;br /&gt;
&lt;br /&gt;
=== SSI / Self-Sovereign Identity ===&lt;br /&gt;
...&lt;br /&gt;
&lt;br /&gt;
== T ==&lt;br /&gt;
&lt;br /&gt;
=== TBD / To Be Determined/Defined ===&lt;br /&gt;
...&lt;br /&gt;
&lt;br /&gt;
=== TEU / Consolidated versions of the Treaty on European Union and the Treaty on the functioning of the European Union (2008/C 115/01) ===&lt;br /&gt;
...&lt;br /&gt;
&lt;br /&gt;
=== TOGAF / The Open Group Architecture Framework ===&lt;br /&gt;
...&lt;br /&gt;
&lt;br /&gt;
=== TOOP / The Once Only Principle Project ===&lt;br /&gt;
...&lt;br /&gt;
&lt;br /&gt;
== U ==&lt;br /&gt;
&lt;br /&gt;
=== UML / Unified Modeling Language ===&lt;br /&gt;
...&lt;br /&gt;
&lt;br /&gt;
== V ==&lt;br /&gt;
...&lt;br /&gt;
&lt;br /&gt;
== W ==&lt;br /&gt;
&lt;br /&gt;
=== WP / Work Package ===&lt;br /&gt;
...&lt;br /&gt;
&lt;br /&gt;
== X ==&lt;br /&gt;
...&lt;br /&gt;
&lt;br /&gt;
== Y ==&lt;br /&gt;
...&lt;br /&gt;
&lt;br /&gt;
== Z ==&lt;br /&gt;
&lt;br /&gt;
=== ZKP / Zero Knowledge Proof ===&lt;br /&gt;
...&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
{{Category:wip}}&lt;/div&gt;</summary>
		<author><name>Ictu mavi.cristache</name></author>
	</entry>
	<entry>
		<id>https://wiki.de4a.eu/index.php?title=Getting_started&amp;diff=3784</id>
		<title>Getting started</title>
		<link rel="alternate" type="text/html" href="https://wiki.de4a.eu/index.php?title=Getting_started&amp;diff=3784"/>
		<updated>2021-11-03T12:07:47Z</updated>

		<summary type="html">&lt;p&gt;Ictu mavi.cristache: /* Sections */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;__NUMBEREDHEADINGS__&lt;br /&gt;
&lt;br /&gt;
[[Category:wip]]&lt;br /&gt;
Welcome, new editor of the DE4A documentation wiki! &lt;br /&gt;
&lt;br /&gt;
Before you beging adding content, you can familiarise yourself in on this page with some basic wiki rules and functionalities. All the tips and instructions listed below are also applied on this page, so feel free to copy syntax from the page source as needed. &lt;br /&gt;
&lt;br /&gt;
''==&amp;gt; Additional help is available in the [[wikipedia:Help:Cheatsheet|Wiki cheat sheet]], the [[mediawikiwiki:Special:MyLanguage/Help:Contents|User's Guide]], and the [[mediawikiwiki:Special:MyLanguage/Manual:FAQ|MediaWiki FAQ]].''&lt;br /&gt;
&lt;br /&gt;
==Ground rules==&lt;br /&gt;
'''#1 Create from search.''' When you want to create a new page, start by searching the wiki for existing content. If the search yields no results, you will be offered the option to create a new page. If you do, make sure your search was capitalised in Title Case. Make sure to also search the list of [[Special:WantedPages|Wanted Pages]] to make use of existing links (where possible) and prevent unwittingly duplicating a page name. &lt;br /&gt;
&lt;br /&gt;
'''#2 Page names in Title Case.''' Page names are capitalised using Wikipedia rules. When in doubt, use this [https://titlecaseconverter.com|Title Case Converter] tool to find the correct capitalisation. Different letter cases produce different wiki pages. For example, &amp;quot;[[Reference Interaction Patterns]]&amp;quot; and &amp;quot;[[Interaction patterns|Reference Interaction patterns]]&amp;quot; will lead to two different pages (the former exists on the DE4A wiki, the latter does not and should not, as it does not follow the Title Case capitalisation rule). &lt;br /&gt;
&lt;br /&gt;
'''#3 Ask for help.''' Don't hesitate to contact the [https://wiki.de4a.eu/index.php/Special:ActiveUsers?username=&amp;amp;groups%5B%5D=interface-admin&amp;amp;wpFormIdentifier=specialactiveusers|DE4A WP2 Team] for advice and support when or before adding your content to the wiki. We're here to think along and help.&lt;br /&gt;
&lt;br /&gt;
== Creating and editing pages  ==&lt;br /&gt;
===Starting a new page===&lt;br /&gt;
You can create a new page from a search or from a red link. In both cases, please observe the Title Case capitalisation rule (#2) above for naming the page. '''Page names cannot be edited anymore once created!''' &lt;br /&gt;
&lt;br /&gt;
''==&amp;gt; For more details see [[mediawikiwiki:Help:Starting_a_new_page|Help:Starting a new page.]]'' &lt;br /&gt;
===Editing===&lt;br /&gt;
You can edit the contents of a page with the Visual Editor or the Source Editor. The Visual Editor provides a direct visual way to edit pages based on the &amp;quot;what you see is what you get&amp;quot; principle. It contains a handy page searching function when inserting links. Visual editing is chosen by clicking the &amp;lt;kbd&amp;gt;Edit&amp;lt;/kbd&amp;gt; tab at the top of a page (or on a section-edit link). The Source Editor can be used for additional functionality with such things as categories, hyperlinks, tables and columns, footnotes, inline citation, special characters and so on. You can access the Source Editor by clicking the &amp;lt;kbd&amp;gt;Edit source&amp;lt;/kbd&amp;gt; tab at the top of a page (or on a section-edit link).  &lt;br /&gt;
&lt;br /&gt;
''==&amp;gt; For more help with the editing interfaces see [[mediawikiwiki:Help:Editing_pages|Help:Editing_pages]] and the [[mediawikiwiki:Help:VisualEditor/User_guide|Visual Editor User Guide]].''  &lt;br /&gt;
&lt;br /&gt;
====Links====&lt;br /&gt;
The most relevant two types of hypertext links in this wiki are internal links to other pages in the same wiki (commonly called &amp;quot;wikilinks&amp;quot;) and external links to pages at other websites. &lt;br /&gt;
&lt;br /&gt;
To create a so-called internal link to a page on the same wiki (a &amp;quot;wikilink&amp;quot;), use double square brackets wiki markup, &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[like this]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;. When you preview or save your changes, you will see a link that can be followed to the target page. If the page exists the link is displayed in blue; if the page does not exist, the link appears red (so the &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[like this]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; link is actually rendered [[like this]]). Following such a &amp;quot;redlink&amp;quot; to a missing page (whether or not it is actually red) will enable you to create the page.&lt;br /&gt;
&lt;br /&gt;
To markup any arbitrary string of text (not necessarily a page title) as a link, use a &amp;quot;vertical bar&amp;quot; or &amp;quot;pipe&amp;quot; character, like this: &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[Main Page|our project]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; results in the link [[Main Page|our project]].&lt;br /&gt;
&lt;br /&gt;
The first letter of the link target is usually not case-sensitive, meaning links can be capitalized or not (so How to contribute and how to contribute are equivalent). However, the case of every ''subsequent'' letter must match the target page exactly (so How to contribute and How To Contribute are ''not'' equivalent). Spaces in the page title may be represented as underscores (so How to contribute and How_to_contribute are again equivalent), but using underscores in links will make them visible in the page text (but this can be prevented by using a &amp;quot;pipe&amp;quot;). Please refer to '''rule #2''' above when naming pages to prevent creating duplicates.  &lt;br /&gt;
&lt;br /&gt;
If the page title you are linking to is that of the page you are editing, the result is not a hyperlink at all but simply bold text (for example, on this page the markup &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[Getting started]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; gives the result [[Getting started]]). If you're trying to create a wikilink to the current page, you probably want to link to a specific ''section'' or to an ''anchor'' within the page. You do that by adding a &amp;quot;#&amp;quot; before the section name: &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[#Ground rules]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; will lead to the [[#Ground rules]] section.&lt;br /&gt;
&lt;br /&gt;
Please note that links open by default in the same browser tab.&lt;br /&gt;
&lt;br /&gt;
''==&amp;gt; For more details see [[mediawikiwiki:Help:Links|Help:Links]]''.&lt;br /&gt;
&lt;br /&gt;
====Formatting====&lt;br /&gt;
&lt;br /&gt;
Formatting text to bold, italic, bulleted or numbered lists, tables etc. is most easily done in the Visual Editor. &lt;br /&gt;
&lt;br /&gt;
If you prefer to use the Source Editor, you can format your text by using wiki markup. This consists of normal characters like asterisks, apostrophes or equal signs which have a special function in the wiki, sometimes depending on their position. For example, to format a word in italic, you include it in two pairs of apostrophes like &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;''this''&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
''==&amp;gt; For more details see [[mediawikiwiki:Help:Formatting|Help:Formatting]] and the [[wikipedia:Help:Cheatsheet|Wiki cheat sheet]]''.&lt;br /&gt;
&lt;br /&gt;
====Sections====&lt;br /&gt;
A page can and should be divided into sections, using the section heading syntax. For each page with more than three section headings, a table of contents (TOC) is automatically generated. &lt;br /&gt;
&lt;br /&gt;
Sections are created by creating their headings, as below.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
== Section ==&lt;br /&gt;
=== Subsection ===&lt;br /&gt;
==== Sub-subsection ====&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Please do not use only one equals sign on a side (&amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;= Heading =&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;). This would cause a section heading to be as large as the page's name (title). The maximum number of equals signs is six. Heading names of sections (including subsections) should be unique on a page. Using the same heading more than once on a page causes problems.&lt;br /&gt;
&lt;br /&gt;
Linking to a section within the same page is done with the &amp;lt;nowiki&amp;gt;[[#Section_name]]&amp;lt;/nowiki&amp;gt; syntax. Linking to a section of another page on the same wiki is done by adding the &amp;quot;#&amp;quot; between the page name and the section name: &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[Page_name#Section_name]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;.  &lt;br /&gt;
&lt;br /&gt;
Section headers can be links to other pages: &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[===This section also has it's own page that can be opened via this link===]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;. The recommended practice is to place an excerpt, a summary or an overview of the dedicated page in the section content of the page being linked from.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;span style=&amp;quot;color:#ff0000&amp;quot;&amp;gt;NEW! Sections can be numbered where necessary. To activate section numbering on a page add this syntax to the page source code (in the source editor): &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt; __ NUMBEREDHEADINGS __ &amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; (without spaces).&amp;lt;/span&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==== Categories ====&lt;br /&gt;
In the DE4A wiki we use categories to indicate the status of a page:&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|+Overview of DE4A wiki page categories&lt;br /&gt;
!Category&lt;br /&gt;
!Description&lt;br /&gt;
|-&lt;br /&gt;
|Wip&lt;br /&gt;
|Page labeled as work In progress, not yet ready for review.&lt;br /&gt;
|-&lt;br /&gt;
|Draft&lt;br /&gt;
|Page labelled as a draft, ready for review.&lt;br /&gt;
|-&lt;br /&gt;
|Released&lt;br /&gt;
|A reviewed and finished page.&lt;br /&gt;
|}&lt;br /&gt;
A category label can be added to a page by inserting &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[Category:wip]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; at the top of the page in the Source Editor. &lt;br /&gt;
&lt;br /&gt;
A category page can be created the same way as other wiki pages; just add &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;Category:&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; before the page title. To avoid extra work, try searching within the wiki before creating a new category. The list of all categories can be found in the #List of pages section of the [[Special:SpecialPages#Lists of pages|Special Pages]] page.&lt;br /&gt;
&lt;br /&gt;
== Uploading files ==&lt;br /&gt;
&lt;br /&gt;
=== Files ===&lt;br /&gt;
Files can be uploaded via the Sidebar menu (Tools &amp;gt; Upload File) or while using the Visual Editor (Insert function). Files can be max 2MB in size and permitted file types are png, gif, jpg, jpeg, webp. Other files can be referenced via external links. Appropriate attention should be paid at all times to copyright and confidentiality considerations. &lt;br /&gt;
&lt;br /&gt;
===Images===&lt;br /&gt;
&lt;br /&gt;
The DE4A wiki includes an extension that makes it possible to display clickable image maps. An image map is a list of coordinates in a specific image, which hyperlinks areas of the image to multiple destinations (in contrast to a normal image link, in which the entire area of the image links to a single destination). For example, an application collaboration diagram may have each component or service hyperlinked to further information about that component or service. The intention of an image map is to provide an easy way of linking various parts of an image without dividing the image into separate image files.&lt;br /&gt;
&lt;br /&gt;
== Special pages ==&lt;br /&gt;
Special pages are pages generated by the wiki software on demand for special purposes, usually related to project maintenance. They can be found in the Tools section of the Sidebar (located on the left side of every page). Useful DE4A wiki special pages include:&lt;br /&gt;
&lt;br /&gt;
* [[Special:AllPages|All pages]] &lt;br /&gt;
* [[Special:ListFiles|Files]]&lt;br /&gt;
* [[Special:WantedPages|Wanted pages (red links)]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[https://wiki.de4a.eu/images/6/69/DE4A_-_VC_SSI-based_interaction_pattern_-_User_Story.pdf Wireframe Mock-up]&lt;/div&gt;</summary>
		<author><name>Ictu mavi.cristache</name></author>
	</entry>
	<entry>
		<id>https://wiki.de4a.eu/index.php?title=Getting_started&amp;diff=3783</id>
		<title>Getting started</title>
		<link rel="alternate" type="text/html" href="https://wiki.de4a.eu/index.php?title=Getting_started&amp;diff=3783"/>
		<updated>2021-11-03T12:06:41Z</updated>

		<summary type="html">&lt;p&gt;Ictu mavi.cristache: /* Sections */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;__NUMBEREDHEADINGS__&lt;br /&gt;
&lt;br /&gt;
[[Category:wip]]&lt;br /&gt;
Welcome, new editor of the DE4A documentation wiki! &lt;br /&gt;
&lt;br /&gt;
Before you beging adding content, you can familiarise yourself in on this page with some basic wiki rules and functionalities. All the tips and instructions listed below are also applied on this page, so feel free to copy syntax from the page source as needed. &lt;br /&gt;
&lt;br /&gt;
''==&amp;gt; Additional help is available in the [[wikipedia:Help:Cheatsheet|Wiki cheat sheet]], the [[mediawikiwiki:Special:MyLanguage/Help:Contents|User's Guide]], and the [[mediawikiwiki:Special:MyLanguage/Manual:FAQ|MediaWiki FAQ]].''&lt;br /&gt;
&lt;br /&gt;
==Ground rules==&lt;br /&gt;
'''#1 Create from search.''' When you want to create a new page, start by searching the wiki for existing content. If the search yields no results, you will be offered the option to create a new page. If you do, make sure your search was capitalised in Title Case. Make sure to also search the list of [[Special:WantedPages|Wanted Pages]] to make use of existing links (where possible) and prevent unwittingly duplicating a page name. &lt;br /&gt;
&lt;br /&gt;
'''#2 Page names in Title Case.''' Page names are capitalised using Wikipedia rules. When in doubt, use this [https://titlecaseconverter.com|Title Case Converter] tool to find the correct capitalisation. Different letter cases produce different wiki pages. For example, &amp;quot;[[Reference Interaction Patterns]]&amp;quot; and &amp;quot;[[Interaction patterns|Reference Interaction patterns]]&amp;quot; will lead to two different pages (the former exists on the DE4A wiki, the latter does not and should not, as it does not follow the Title Case capitalisation rule). &lt;br /&gt;
&lt;br /&gt;
'''#3 Ask for help.''' Don't hesitate to contact the [https://wiki.de4a.eu/index.php/Special:ActiveUsers?username=&amp;amp;groups%5B%5D=interface-admin&amp;amp;wpFormIdentifier=specialactiveusers|DE4A WP2 Team] for advice and support when or before adding your content to the wiki. We're here to think along and help.&lt;br /&gt;
&lt;br /&gt;
== Creating and editing pages  ==&lt;br /&gt;
===Starting a new page===&lt;br /&gt;
You can create a new page from a search or from a red link. In both cases, please observe the Title Case capitalisation rule (#2) above for naming the page. '''Page names cannot be edited anymore once created!''' &lt;br /&gt;
&lt;br /&gt;
''==&amp;gt; For more details see [[mediawikiwiki:Help:Starting_a_new_page|Help:Starting a new page.]]'' &lt;br /&gt;
===Editing===&lt;br /&gt;
You can edit the contents of a page with the Visual Editor or the Source Editor. The Visual Editor provides a direct visual way to edit pages based on the &amp;quot;what you see is what you get&amp;quot; principle. It contains a handy page searching function when inserting links. Visual editing is chosen by clicking the &amp;lt;kbd&amp;gt;Edit&amp;lt;/kbd&amp;gt; tab at the top of a page (or on a section-edit link). The Source Editor can be used for additional functionality with such things as categories, hyperlinks, tables and columns, footnotes, inline citation, special characters and so on. You can access the Source Editor by clicking the &amp;lt;kbd&amp;gt;Edit source&amp;lt;/kbd&amp;gt; tab at the top of a page (or on a section-edit link).  &lt;br /&gt;
&lt;br /&gt;
''==&amp;gt; For more help with the editing interfaces see [[mediawikiwiki:Help:Editing_pages|Help:Editing_pages]] and the [[mediawikiwiki:Help:VisualEditor/User_guide|Visual Editor User Guide]].''  &lt;br /&gt;
&lt;br /&gt;
====Links====&lt;br /&gt;
The most relevant two types of hypertext links in this wiki are internal links to other pages in the same wiki (commonly called &amp;quot;wikilinks&amp;quot;) and external links to pages at other websites. &lt;br /&gt;
&lt;br /&gt;
To create a so-called internal link to a page on the same wiki (a &amp;quot;wikilink&amp;quot;), use double square brackets wiki markup, &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[like this]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;. When you preview or save your changes, you will see a link that can be followed to the target page. If the page exists the link is displayed in blue; if the page does not exist, the link appears red (so the &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[like this]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; link is actually rendered [[like this]]). Following such a &amp;quot;redlink&amp;quot; to a missing page (whether or not it is actually red) will enable you to create the page.&lt;br /&gt;
&lt;br /&gt;
To markup any arbitrary string of text (not necessarily a page title) as a link, use a &amp;quot;vertical bar&amp;quot; or &amp;quot;pipe&amp;quot; character, like this: &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[Main Page|our project]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; results in the link [[Main Page|our project]].&lt;br /&gt;
&lt;br /&gt;
The first letter of the link target is usually not case-sensitive, meaning links can be capitalized or not (so How to contribute and how to contribute are equivalent). However, the case of every ''subsequent'' letter must match the target page exactly (so How to contribute and How To Contribute are ''not'' equivalent). Spaces in the page title may be represented as underscores (so How to contribute and How_to_contribute are again equivalent), but using underscores in links will make them visible in the page text (but this can be prevented by using a &amp;quot;pipe&amp;quot;). Please refer to '''rule #2''' above when naming pages to prevent creating duplicates.  &lt;br /&gt;
&lt;br /&gt;
If the page title you are linking to is that of the page you are editing, the result is not a hyperlink at all but simply bold text (for example, on this page the markup &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[Getting started]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; gives the result [[Getting started]]). If you're trying to create a wikilink to the current page, you probably want to link to a specific ''section'' or to an ''anchor'' within the page. You do that by adding a &amp;quot;#&amp;quot; before the section name: &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[#Ground rules]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; will lead to the [[#Ground rules]] section.&lt;br /&gt;
&lt;br /&gt;
Please note that links open by default in the same browser tab.&lt;br /&gt;
&lt;br /&gt;
''==&amp;gt; For more details see [[mediawikiwiki:Help:Links|Help:Links]]''.&lt;br /&gt;
&lt;br /&gt;
====Formatting====&lt;br /&gt;
&lt;br /&gt;
Formatting text to bold, italic, bulleted or numbered lists, tables etc. is most easily done in the Visual Editor. &lt;br /&gt;
&lt;br /&gt;
If you prefer to use the Source Editor, you can format your text by using wiki markup. This consists of normal characters like asterisks, apostrophes or equal signs which have a special function in the wiki, sometimes depending on their position. For example, to format a word in italic, you include it in two pairs of apostrophes like &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;''this''&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
''==&amp;gt; For more details see [[mediawikiwiki:Help:Formatting|Help:Formatting]] and the [[wikipedia:Help:Cheatsheet|Wiki cheat sheet]]''.&lt;br /&gt;
&lt;br /&gt;
====Sections====&lt;br /&gt;
A page can and should be divided into sections, using the section heading syntax. For each page with more than three section headings, a table of contents (TOC) is automatically generated. &lt;br /&gt;
&lt;br /&gt;
Sections are created by creating their headings, as below.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
== Section ==&lt;br /&gt;
=== Subsection ===&lt;br /&gt;
==== Sub-subsection ====&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Please do not use only one equals sign on a side (&amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;= Heading =&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;). This would cause a section heading to be as large as the page's name (title). The maximum number of equals signs is six. Heading names of sections (including subsections) should be unique on a page. Using the same heading more than once on a page causes problems.&lt;br /&gt;
&lt;br /&gt;
Linking to a section within the same page is done with the &amp;lt;nowiki&amp;gt;[[#Section_name]]&amp;lt;/nowiki&amp;gt; syntax. Linking to a section of another page on the same wiki is done by adding the &amp;quot;#&amp;quot; between the page name and the section name: &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[Page_name#Section_name]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;.  &lt;br /&gt;
&lt;br /&gt;
Section headers can be links to other pages: &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[===This section also has it's own page that can be opened via this link===]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;. The recommended practice is to place an excerpt, a summary or an overview of the dedicated page in the section content of the page being linked from.&lt;br /&gt;
&lt;br /&gt;
NEW! Sections can be numbered where necessary. To activate section numbering on a page add this syntax to the page source code (in the source editor): &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt; __ NUMBEREDHEADINGS __ &amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; (without spaces).&lt;br /&gt;
&lt;br /&gt;
==== Categories ====&lt;br /&gt;
In the DE4A wiki we use categories to indicate the status of a page:&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|+Overview of DE4A wiki page categories&lt;br /&gt;
!Category&lt;br /&gt;
!Description&lt;br /&gt;
|-&lt;br /&gt;
|Wip&lt;br /&gt;
|Page labeled as work In progress, not yet ready for review.&lt;br /&gt;
|-&lt;br /&gt;
|Draft&lt;br /&gt;
|Page labelled as a draft, ready for review.&lt;br /&gt;
|-&lt;br /&gt;
|Released&lt;br /&gt;
|A reviewed and finished page.&lt;br /&gt;
|}&lt;br /&gt;
A category label can be added to a page by inserting &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[Category:wip]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; at the top of the page in the Source Editor. &lt;br /&gt;
&lt;br /&gt;
A category page can be created the same way as other wiki pages; just add &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;Category:&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; before the page title. To avoid extra work, try searching within the wiki before creating a new category. The list of all categories can be found in the #List of pages section of the [[Special:SpecialPages#Lists of pages|Special Pages]] page.&lt;br /&gt;
&lt;br /&gt;
== Uploading files ==&lt;br /&gt;
&lt;br /&gt;
=== Files ===&lt;br /&gt;
Files can be uploaded via the Sidebar menu (Tools &amp;gt; Upload File) or while using the Visual Editor (Insert function). Files can be max 2MB in size and permitted file types are png, gif, jpg, jpeg, webp. Other files can be referenced via external links. Appropriate attention should be paid at all times to copyright and confidentiality considerations. &lt;br /&gt;
&lt;br /&gt;
===Images===&lt;br /&gt;
&lt;br /&gt;
The DE4A wiki includes an extension that makes it possible to display clickable image maps. An image map is a list of coordinates in a specific image, which hyperlinks areas of the image to multiple destinations (in contrast to a normal image link, in which the entire area of the image links to a single destination). For example, an application collaboration diagram may have each component or service hyperlinked to further information about that component or service. The intention of an image map is to provide an easy way of linking various parts of an image without dividing the image into separate image files.&lt;br /&gt;
&lt;br /&gt;
== Special pages ==&lt;br /&gt;
Special pages are pages generated by the wiki software on demand for special purposes, usually related to project maintenance. They can be found in the Tools section of the Sidebar (located on the left side of every page). Useful DE4A wiki special pages include:&lt;br /&gt;
&lt;br /&gt;
* [[Special:AllPages|All pages]] &lt;br /&gt;
* [[Special:ListFiles|Files]]&lt;br /&gt;
* [[Special:WantedPages|Wanted pages (red links)]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[https://wiki.de4a.eu/images/6/69/DE4A_-_VC_SSI-based_interaction_pattern_-_User_Story.pdf Wireframe Mock-up]&lt;/div&gt;</summary>
		<author><name>Ictu mavi.cristache</name></author>
	</entry>
	<entry>
		<id>https://wiki.de4a.eu/index.php?title=Getting_started&amp;diff=3782</id>
		<title>Getting started</title>
		<link rel="alternate" type="text/html" href="https://wiki.de4a.eu/index.php?title=Getting_started&amp;diff=3782"/>
		<updated>2021-11-03T12:05:09Z</updated>

		<summary type="html">&lt;p&gt;Ictu mavi.cristache: /* Sections */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;__NUMBEREDHEADINGS__&lt;br /&gt;
&lt;br /&gt;
[[Category:wip]]&lt;br /&gt;
Welcome, new editor of the DE4A documentation wiki! &lt;br /&gt;
&lt;br /&gt;
Before you beging adding content, you can familiarise yourself in on this page with some basic wiki rules and functionalities. All the tips and instructions listed below are also applied on this page, so feel free to copy syntax from the page source as needed. &lt;br /&gt;
&lt;br /&gt;
''==&amp;gt; Additional help is available in the [[wikipedia:Help:Cheatsheet|Wiki cheat sheet]], the [[mediawikiwiki:Special:MyLanguage/Help:Contents|User's Guide]], and the [[mediawikiwiki:Special:MyLanguage/Manual:FAQ|MediaWiki FAQ]].''&lt;br /&gt;
&lt;br /&gt;
==Ground rules==&lt;br /&gt;
'''#1 Create from search.''' When you want to create a new page, start by searching the wiki for existing content. If the search yields no results, you will be offered the option to create a new page. If you do, make sure your search was capitalised in Title Case. Make sure to also search the list of [[Special:WantedPages|Wanted Pages]] to make use of existing links (where possible) and prevent unwittingly duplicating a page name. &lt;br /&gt;
&lt;br /&gt;
'''#2 Page names in Title Case.''' Page names are capitalised using Wikipedia rules. When in doubt, use this [https://titlecaseconverter.com|Title Case Converter] tool to find the correct capitalisation. Different letter cases produce different wiki pages. For example, &amp;quot;[[Reference Interaction Patterns]]&amp;quot; and &amp;quot;[[Interaction patterns|Reference Interaction patterns]]&amp;quot; will lead to two different pages (the former exists on the DE4A wiki, the latter does not and should not, as it does not follow the Title Case capitalisation rule). &lt;br /&gt;
&lt;br /&gt;
'''#3 Ask for help.''' Don't hesitate to contact the [https://wiki.de4a.eu/index.php/Special:ActiveUsers?username=&amp;amp;groups%5B%5D=interface-admin&amp;amp;wpFormIdentifier=specialactiveusers|DE4A WP2 Team] for advice and support when or before adding your content to the wiki. We're here to think along and help.&lt;br /&gt;
&lt;br /&gt;
== Creating and editing pages  ==&lt;br /&gt;
===Starting a new page===&lt;br /&gt;
You can create a new page from a search or from a red link. In both cases, please observe the Title Case capitalisation rule (#2) above for naming the page. '''Page names cannot be edited anymore once created!''' &lt;br /&gt;
&lt;br /&gt;
''==&amp;gt; For more details see [[mediawikiwiki:Help:Starting_a_new_page|Help:Starting a new page.]]'' &lt;br /&gt;
===Editing===&lt;br /&gt;
You can edit the contents of a page with the Visual Editor or the Source Editor. The Visual Editor provides a direct visual way to edit pages based on the &amp;quot;what you see is what you get&amp;quot; principle. It contains a handy page searching function when inserting links. Visual editing is chosen by clicking the &amp;lt;kbd&amp;gt;Edit&amp;lt;/kbd&amp;gt; tab at the top of a page (or on a section-edit link). The Source Editor can be used for additional functionality with such things as categories, hyperlinks, tables and columns, footnotes, inline citation, special characters and so on. You can access the Source Editor by clicking the &amp;lt;kbd&amp;gt;Edit source&amp;lt;/kbd&amp;gt; tab at the top of a page (or on a section-edit link).  &lt;br /&gt;
&lt;br /&gt;
''==&amp;gt; For more help with the editing interfaces see [[mediawikiwiki:Help:Editing_pages|Help:Editing_pages]] and the [[mediawikiwiki:Help:VisualEditor/User_guide|Visual Editor User Guide]].''  &lt;br /&gt;
&lt;br /&gt;
====Links====&lt;br /&gt;
The most relevant two types of hypertext links in this wiki are internal links to other pages in the same wiki (commonly called &amp;quot;wikilinks&amp;quot;) and external links to pages at other websites. &lt;br /&gt;
&lt;br /&gt;
To create a so-called internal link to a page on the same wiki (a &amp;quot;wikilink&amp;quot;), use double square brackets wiki markup, &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[like this]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;. When you preview or save your changes, you will see a link that can be followed to the target page. If the page exists the link is displayed in blue; if the page does not exist, the link appears red (so the &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[like this]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; link is actually rendered [[like this]]). Following such a &amp;quot;redlink&amp;quot; to a missing page (whether or not it is actually red) will enable you to create the page.&lt;br /&gt;
&lt;br /&gt;
To markup any arbitrary string of text (not necessarily a page title) as a link, use a &amp;quot;vertical bar&amp;quot; or &amp;quot;pipe&amp;quot; character, like this: &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[Main Page|our project]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; results in the link [[Main Page|our project]].&lt;br /&gt;
&lt;br /&gt;
The first letter of the link target is usually not case-sensitive, meaning links can be capitalized or not (so How to contribute and how to contribute are equivalent). However, the case of every ''subsequent'' letter must match the target page exactly (so How to contribute and How To Contribute are ''not'' equivalent). Spaces in the page title may be represented as underscores (so How to contribute and How_to_contribute are again equivalent), but using underscores in links will make them visible in the page text (but this can be prevented by using a &amp;quot;pipe&amp;quot;). Please refer to '''rule #2''' above when naming pages to prevent creating duplicates.  &lt;br /&gt;
&lt;br /&gt;
If the page title you are linking to is that of the page you are editing, the result is not a hyperlink at all but simply bold text (for example, on this page the markup &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[Getting started]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; gives the result [[Getting started]]). If you're trying to create a wikilink to the current page, you probably want to link to a specific ''section'' or to an ''anchor'' within the page. You do that by adding a &amp;quot;#&amp;quot; before the section name: &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[#Ground rules]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; will lead to the [[#Ground rules]] section.&lt;br /&gt;
&lt;br /&gt;
Please note that links open by default in the same browser tab.&lt;br /&gt;
&lt;br /&gt;
''==&amp;gt; For more details see [[mediawikiwiki:Help:Links|Help:Links]]''.&lt;br /&gt;
&lt;br /&gt;
====Formatting====&lt;br /&gt;
&lt;br /&gt;
Formatting text to bold, italic, bulleted or numbered lists, tables etc. is most easily done in the Visual Editor. &lt;br /&gt;
&lt;br /&gt;
If you prefer to use the Source Editor, you can format your text by using wiki markup. This consists of normal characters like asterisks, apostrophes or equal signs which have a special function in the wiki, sometimes depending on their position. For example, to format a word in italic, you include it in two pairs of apostrophes like &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;''this''&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
''==&amp;gt; For more details see [[mediawikiwiki:Help:Formatting|Help:Formatting]] and the [[wikipedia:Help:Cheatsheet|Wiki cheat sheet]]''.&lt;br /&gt;
&lt;br /&gt;
====Sections====&lt;br /&gt;
A page can and should be divided into sections, using the section heading syntax. For each page with more than three section headings, a table of contents (TOC) is automatically generated. &lt;br /&gt;
&lt;br /&gt;
Sections are created by creating their headings, as below.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
== Section ==&lt;br /&gt;
=== Subsection ===&lt;br /&gt;
==== Sub-subsection ====&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Please do not use only one equals sign on a side (&amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;= Heading =&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;). This would cause a section heading to be as large as the page's name (title). The maximum number of equals signs is six. Heading names of sections (including subsections) should be unique on a page. Using the same heading more than once on a page causes problems.&lt;br /&gt;
&lt;br /&gt;
Linking to a section within the same page is done with the &amp;lt;nowiki&amp;gt;[[#Section_name]]&amp;lt;/nowiki&amp;gt; syntax. Linking to a section of another page on the same wiki is done by adding the &amp;quot;#&amp;quot; between the page name and the section name: &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[Page_name#Section_name]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;.  &lt;br /&gt;
&lt;br /&gt;
Section headers can be links to other pages: &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[===This section also has it's own page that can be opened via this link===]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;. The recommended practice is to place an excerpt, a summary or an overview of the dedicated page in the section content of the page being linked from.&lt;br /&gt;
&lt;br /&gt;
NEW! Sections can be numbered where necessary. To activate section numbering on a page add this syntax to the page source code (in the source editor): &amp;lt;nowiki&amp;gt; __NUMBEREDHEADINGS__ &amp;lt;/nowiki&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
==== Categories ====&lt;br /&gt;
In the DE4A wiki we use categories to indicate the status of a page:&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|+Overview of DE4A wiki page categories&lt;br /&gt;
!Category&lt;br /&gt;
!Description&lt;br /&gt;
|-&lt;br /&gt;
|Wip&lt;br /&gt;
|Page labeled as work In progress, not yet ready for review.&lt;br /&gt;
|-&lt;br /&gt;
|Draft&lt;br /&gt;
|Page labelled as a draft, ready for review.&lt;br /&gt;
|-&lt;br /&gt;
|Released&lt;br /&gt;
|A reviewed and finished page.&lt;br /&gt;
|}&lt;br /&gt;
A category label can be added to a page by inserting &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[Category:wip]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; at the top of the page in the Source Editor. &lt;br /&gt;
&lt;br /&gt;
A category page can be created the same way as other wiki pages; just add &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;Category:&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; before the page title. To avoid extra work, try searching within the wiki before creating a new category. The list of all categories can be found in the #List of pages section of the [[Special:SpecialPages#Lists of pages|Special Pages]] page.&lt;br /&gt;
&lt;br /&gt;
== Uploading files ==&lt;br /&gt;
&lt;br /&gt;
=== Files ===&lt;br /&gt;
Files can be uploaded via the Sidebar menu (Tools &amp;gt; Upload File) or while using the Visual Editor (Insert function). Files can be max 2MB in size and permitted file types are png, gif, jpg, jpeg, webp. Other files can be referenced via external links. Appropriate attention should be paid at all times to copyright and confidentiality considerations. &lt;br /&gt;
&lt;br /&gt;
===Images===&lt;br /&gt;
&lt;br /&gt;
The DE4A wiki includes an extension that makes it possible to display clickable image maps. An image map is a list of coordinates in a specific image, which hyperlinks areas of the image to multiple destinations (in contrast to a normal image link, in which the entire area of the image links to a single destination). For example, an application collaboration diagram may have each component or service hyperlinked to further information about that component or service. The intention of an image map is to provide an easy way of linking various parts of an image without dividing the image into separate image files.&lt;br /&gt;
&lt;br /&gt;
== Special pages ==&lt;br /&gt;
Special pages are pages generated by the wiki software on demand for special purposes, usually related to project maintenance. They can be found in the Tools section of the Sidebar (located on the left side of every page). Useful DE4A wiki special pages include:&lt;br /&gt;
&lt;br /&gt;
* [[Special:AllPages|All pages]] &lt;br /&gt;
* [[Special:ListFiles|Files]]&lt;br /&gt;
* [[Special:WantedPages|Wanted pages (red links)]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[https://wiki.de4a.eu/images/6/69/DE4A_-_VC_SSI-based_interaction_pattern_-_User_Story.pdf Wireframe Mock-up]&lt;/div&gt;</summary>
		<author><name>Ictu mavi.cristache</name></author>
	</entry>
	<entry>
		<id>https://wiki.de4a.eu/index.php?title=Getting_started&amp;diff=3781</id>
		<title>Getting started</title>
		<link rel="alternate" type="text/html" href="https://wiki.de4a.eu/index.php?title=Getting_started&amp;diff=3781"/>
		<updated>2021-11-03T12:03:55Z</updated>

		<summary type="html">&lt;p&gt;Ictu mavi.cristache: /* Sections */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;__NUMBEREDHEADINGS__&lt;br /&gt;
&lt;br /&gt;
[[Category:wip]]&lt;br /&gt;
Welcome, new editor of the DE4A documentation wiki! &lt;br /&gt;
&lt;br /&gt;
Before you beging adding content, you can familiarise yourself in on this page with some basic wiki rules and functionalities. All the tips and instructions listed below are also applied on this page, so feel free to copy syntax from the page source as needed. &lt;br /&gt;
&lt;br /&gt;
''==&amp;gt; Additional help is available in the [[wikipedia:Help:Cheatsheet|Wiki cheat sheet]], the [[mediawikiwiki:Special:MyLanguage/Help:Contents|User's Guide]], and the [[mediawikiwiki:Special:MyLanguage/Manual:FAQ|MediaWiki FAQ]].''&lt;br /&gt;
&lt;br /&gt;
==Ground rules==&lt;br /&gt;
'''#1 Create from search.''' When you want to create a new page, start by searching the wiki for existing content. If the search yields no results, you will be offered the option to create a new page. If you do, make sure your search was capitalised in Title Case. Make sure to also search the list of [[Special:WantedPages|Wanted Pages]] to make use of existing links (where possible) and prevent unwittingly duplicating a page name. &lt;br /&gt;
&lt;br /&gt;
'''#2 Page names in Title Case.''' Page names are capitalised using Wikipedia rules. When in doubt, use this [https://titlecaseconverter.com|Title Case Converter] tool to find the correct capitalisation. Different letter cases produce different wiki pages. For example, &amp;quot;[[Reference Interaction Patterns]]&amp;quot; and &amp;quot;[[Interaction patterns|Reference Interaction patterns]]&amp;quot; will lead to two different pages (the former exists on the DE4A wiki, the latter does not and should not, as it does not follow the Title Case capitalisation rule). &lt;br /&gt;
&lt;br /&gt;
'''#3 Ask for help.''' Don't hesitate to contact the [https://wiki.de4a.eu/index.php/Special:ActiveUsers?username=&amp;amp;groups%5B%5D=interface-admin&amp;amp;wpFormIdentifier=specialactiveusers|DE4A WP2 Team] for advice and support when or before adding your content to the wiki. We're here to think along and help.&lt;br /&gt;
&lt;br /&gt;
== Creating and editing pages  ==&lt;br /&gt;
===Starting a new page===&lt;br /&gt;
You can create a new page from a search or from a red link. In both cases, please observe the Title Case capitalisation rule (#2) above for naming the page. '''Page names cannot be edited anymore once created!''' &lt;br /&gt;
&lt;br /&gt;
''==&amp;gt; For more details see [[mediawikiwiki:Help:Starting_a_new_page|Help:Starting a new page.]]'' &lt;br /&gt;
===Editing===&lt;br /&gt;
You can edit the contents of a page with the Visual Editor or the Source Editor. The Visual Editor provides a direct visual way to edit pages based on the &amp;quot;what you see is what you get&amp;quot; principle. It contains a handy page searching function when inserting links. Visual editing is chosen by clicking the &amp;lt;kbd&amp;gt;Edit&amp;lt;/kbd&amp;gt; tab at the top of a page (or on a section-edit link). The Source Editor can be used for additional functionality with such things as categories, hyperlinks, tables and columns, footnotes, inline citation, special characters and so on. You can access the Source Editor by clicking the &amp;lt;kbd&amp;gt;Edit source&amp;lt;/kbd&amp;gt; tab at the top of a page (or on a section-edit link).  &lt;br /&gt;
&lt;br /&gt;
''==&amp;gt; For more help with the editing interfaces see [[mediawikiwiki:Help:Editing_pages|Help:Editing_pages]] and the [[mediawikiwiki:Help:VisualEditor/User_guide|Visual Editor User Guide]].''  &lt;br /&gt;
&lt;br /&gt;
====Links====&lt;br /&gt;
The most relevant two types of hypertext links in this wiki are internal links to other pages in the same wiki (commonly called &amp;quot;wikilinks&amp;quot;) and external links to pages at other websites. &lt;br /&gt;
&lt;br /&gt;
To create a so-called internal link to a page on the same wiki (a &amp;quot;wikilink&amp;quot;), use double square brackets wiki markup, &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[like this]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;. When you preview or save your changes, you will see a link that can be followed to the target page. If the page exists the link is displayed in blue; if the page does not exist, the link appears red (so the &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[like this]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; link is actually rendered [[like this]]). Following such a &amp;quot;redlink&amp;quot; to a missing page (whether or not it is actually red) will enable you to create the page.&lt;br /&gt;
&lt;br /&gt;
To markup any arbitrary string of text (not necessarily a page title) as a link, use a &amp;quot;vertical bar&amp;quot; or &amp;quot;pipe&amp;quot; character, like this: &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[Main Page|our project]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; results in the link [[Main Page|our project]].&lt;br /&gt;
&lt;br /&gt;
The first letter of the link target is usually not case-sensitive, meaning links can be capitalized or not (so How to contribute and how to contribute are equivalent). However, the case of every ''subsequent'' letter must match the target page exactly (so How to contribute and How To Contribute are ''not'' equivalent). Spaces in the page title may be represented as underscores (so How to contribute and How_to_contribute are again equivalent), but using underscores in links will make them visible in the page text (but this can be prevented by using a &amp;quot;pipe&amp;quot;). Please refer to '''rule #2''' above when naming pages to prevent creating duplicates.  &lt;br /&gt;
&lt;br /&gt;
If the page title you are linking to is that of the page you are editing, the result is not a hyperlink at all but simply bold text (for example, on this page the markup &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[Getting started]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; gives the result [[Getting started]]). If you're trying to create a wikilink to the current page, you probably want to link to a specific ''section'' or to an ''anchor'' within the page. You do that by adding a &amp;quot;#&amp;quot; before the section name: &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[#Ground rules]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; will lead to the [[#Ground rules]] section.&lt;br /&gt;
&lt;br /&gt;
Please note that links open by default in the same browser tab.&lt;br /&gt;
&lt;br /&gt;
''==&amp;gt; For more details see [[mediawikiwiki:Help:Links|Help:Links]]''.&lt;br /&gt;
&lt;br /&gt;
====Formatting====&lt;br /&gt;
&lt;br /&gt;
Formatting text to bold, italic, bulleted or numbered lists, tables etc. is most easily done in the Visual Editor. &lt;br /&gt;
&lt;br /&gt;
If you prefer to use the Source Editor, you can format your text by using wiki markup. This consists of normal characters like asterisks, apostrophes or equal signs which have a special function in the wiki, sometimes depending on their position. For example, to format a word in italic, you include it in two pairs of apostrophes like &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;''this''&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
''==&amp;gt; For more details see [[mediawikiwiki:Help:Formatting|Help:Formatting]] and the [[wikipedia:Help:Cheatsheet|Wiki cheat sheet]]''.&lt;br /&gt;
&lt;br /&gt;
====Sections====&lt;br /&gt;
A page can and should be divided into sections, using the section heading syntax. For each page with more than three section headings, a table of contents (TOC) is automatically generated. &lt;br /&gt;
&lt;br /&gt;
Sections are created by creating their headings, as below.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
== Section ==&lt;br /&gt;
=== Subsection ===&lt;br /&gt;
==== Sub-subsection ====&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Please do not use only one equals sign on a side (&amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;= Heading =&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;). This would cause a section heading to be as large as the page's name (title). The maximum number of equals signs is six. Heading names of sections (including subsections) should be unique on a page. Using the same heading more than once on a page causes problems.&lt;br /&gt;
&lt;br /&gt;
Linking to a section within the same page is done with the &amp;lt;nowiki&amp;gt;[[#Section_name]]&amp;lt;/nowiki&amp;gt; syntax. Linking to a section of another page on the same wiki is done by adding the &amp;quot;#&amp;quot; between the page name and the section name: &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[Page_name#Section_name]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;.  &lt;br /&gt;
&lt;br /&gt;
Section headers can be links to other pages: &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[===This section also has it's own page that can be opened via this link===]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;. The recommended practice is to place an excerpt, a summary or an overview of the dedicated page in the section content of the page being linked from.&lt;br /&gt;
&lt;br /&gt;
NEW! Sections can be numbered where necessary. To activate section numbering on a page add this syntax to the page source code (in the source editor): &amp;lt;nowiki&amp;gt;&amp;lt;code&amp;gt;__NUMBEREDHEADINGS__&amp;lt;/code&amp;gt;&amp;lt;/nowiki&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
==== Categories ====&lt;br /&gt;
In the DE4A wiki we use categories to indicate the status of a page:&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|+Overview of DE4A wiki page categories&lt;br /&gt;
!Category&lt;br /&gt;
!Description&lt;br /&gt;
|-&lt;br /&gt;
|Wip&lt;br /&gt;
|Page labeled as work In progress, not yet ready for review.&lt;br /&gt;
|-&lt;br /&gt;
|Draft&lt;br /&gt;
|Page labelled as a draft, ready for review.&lt;br /&gt;
|-&lt;br /&gt;
|Released&lt;br /&gt;
|A reviewed and finished page.&lt;br /&gt;
|}&lt;br /&gt;
A category label can be added to a page by inserting &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[Category:wip]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; at the top of the page in the Source Editor. &lt;br /&gt;
&lt;br /&gt;
A category page can be created the same way as other wiki pages; just add &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;Category:&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; before the page title. To avoid extra work, try searching within the wiki before creating a new category. The list of all categories can be found in the #List of pages section of the [[Special:SpecialPages#Lists of pages|Special Pages]] page.&lt;br /&gt;
&lt;br /&gt;
== Uploading files ==&lt;br /&gt;
&lt;br /&gt;
=== Files ===&lt;br /&gt;
Files can be uploaded via the Sidebar menu (Tools &amp;gt; Upload File) or while using the Visual Editor (Insert function). Files can be max 2MB in size and permitted file types are png, gif, jpg, jpeg, webp. Other files can be referenced via external links. Appropriate attention should be paid at all times to copyright and confidentiality considerations. &lt;br /&gt;
&lt;br /&gt;
===Images===&lt;br /&gt;
&lt;br /&gt;
The DE4A wiki includes an extension that makes it possible to display clickable image maps. An image map is a list of coordinates in a specific image, which hyperlinks areas of the image to multiple destinations (in contrast to a normal image link, in which the entire area of the image links to a single destination). For example, an application collaboration diagram may have each component or service hyperlinked to further information about that component or service. The intention of an image map is to provide an easy way of linking various parts of an image without dividing the image into separate image files.&lt;br /&gt;
&lt;br /&gt;
== Special pages ==&lt;br /&gt;
Special pages are pages generated by the wiki software on demand for special purposes, usually related to project maintenance. They can be found in the Tools section of the Sidebar (located on the left side of every page). Useful DE4A wiki special pages include:&lt;br /&gt;
&lt;br /&gt;
* [[Special:AllPages|All pages]] &lt;br /&gt;
* [[Special:ListFiles|Files]]&lt;br /&gt;
* [[Special:WantedPages|Wanted pages (red links)]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[https://wiki.de4a.eu/images/6/69/DE4A_-_VC_SSI-based_interaction_pattern_-_User_Story.pdf Wireframe Mock-up]&lt;/div&gt;</summary>
		<author><name>Ictu mavi.cristache</name></author>
	</entry>
	<entry>
		<id>https://wiki.de4a.eu/index.php?title=Getting_started&amp;diff=3780</id>
		<title>Getting started</title>
		<link rel="alternate" type="text/html" href="https://wiki.de4a.eu/index.php?title=Getting_started&amp;diff=3780"/>
		<updated>2021-11-03T12:02:58Z</updated>

		<summary type="html">&lt;p&gt;Ictu mavi.cristache: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;__NUMBEREDHEADINGS__&lt;br /&gt;
&lt;br /&gt;
[[Category:wip]]&lt;br /&gt;
Welcome, new editor of the DE4A documentation wiki! &lt;br /&gt;
&lt;br /&gt;
Before you beging adding content, you can familiarise yourself in on this page with some basic wiki rules and functionalities. All the tips and instructions listed below are also applied on this page, so feel free to copy syntax from the page source as needed. &lt;br /&gt;
&lt;br /&gt;
''==&amp;gt; Additional help is available in the [[wikipedia:Help:Cheatsheet|Wiki cheat sheet]], the [[mediawikiwiki:Special:MyLanguage/Help:Contents|User's Guide]], and the [[mediawikiwiki:Special:MyLanguage/Manual:FAQ|MediaWiki FAQ]].''&lt;br /&gt;
&lt;br /&gt;
==Ground rules==&lt;br /&gt;
'''#1 Create from search.''' When you want to create a new page, start by searching the wiki for existing content. If the search yields no results, you will be offered the option to create a new page. If you do, make sure your search was capitalised in Title Case. Make sure to also search the list of [[Special:WantedPages|Wanted Pages]] to make use of existing links (where possible) and prevent unwittingly duplicating a page name. &lt;br /&gt;
&lt;br /&gt;
'''#2 Page names in Title Case.''' Page names are capitalised using Wikipedia rules. When in doubt, use this [https://titlecaseconverter.com|Title Case Converter] tool to find the correct capitalisation. Different letter cases produce different wiki pages. For example, &amp;quot;[[Reference Interaction Patterns]]&amp;quot; and &amp;quot;[[Interaction patterns|Reference Interaction patterns]]&amp;quot; will lead to two different pages (the former exists on the DE4A wiki, the latter does not and should not, as it does not follow the Title Case capitalisation rule). &lt;br /&gt;
&lt;br /&gt;
'''#3 Ask for help.''' Don't hesitate to contact the [https://wiki.de4a.eu/index.php/Special:ActiveUsers?username=&amp;amp;groups%5B%5D=interface-admin&amp;amp;wpFormIdentifier=specialactiveusers|DE4A WP2 Team] for advice and support when or before adding your content to the wiki. We're here to think along and help.&lt;br /&gt;
&lt;br /&gt;
== Creating and editing pages  ==&lt;br /&gt;
===Starting a new page===&lt;br /&gt;
You can create a new page from a search or from a red link. In both cases, please observe the Title Case capitalisation rule (#2) above for naming the page. '''Page names cannot be edited anymore once created!''' &lt;br /&gt;
&lt;br /&gt;
''==&amp;gt; For more details see [[mediawikiwiki:Help:Starting_a_new_page|Help:Starting a new page.]]'' &lt;br /&gt;
===Editing===&lt;br /&gt;
You can edit the contents of a page with the Visual Editor or the Source Editor. The Visual Editor provides a direct visual way to edit pages based on the &amp;quot;what you see is what you get&amp;quot; principle. It contains a handy page searching function when inserting links. Visual editing is chosen by clicking the &amp;lt;kbd&amp;gt;Edit&amp;lt;/kbd&amp;gt; tab at the top of a page (or on a section-edit link). The Source Editor can be used for additional functionality with such things as categories, hyperlinks, tables and columns, footnotes, inline citation, special characters and so on. You can access the Source Editor by clicking the &amp;lt;kbd&amp;gt;Edit source&amp;lt;/kbd&amp;gt; tab at the top of a page (or on a section-edit link).  &lt;br /&gt;
&lt;br /&gt;
''==&amp;gt; For more help with the editing interfaces see [[mediawikiwiki:Help:Editing_pages|Help:Editing_pages]] and the [[mediawikiwiki:Help:VisualEditor/User_guide|Visual Editor User Guide]].''  &lt;br /&gt;
&lt;br /&gt;
====Links====&lt;br /&gt;
The most relevant two types of hypertext links in this wiki are internal links to other pages in the same wiki (commonly called &amp;quot;wikilinks&amp;quot;) and external links to pages at other websites. &lt;br /&gt;
&lt;br /&gt;
To create a so-called internal link to a page on the same wiki (a &amp;quot;wikilink&amp;quot;), use double square brackets wiki markup, &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[like this]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;. When you preview or save your changes, you will see a link that can be followed to the target page. If the page exists the link is displayed in blue; if the page does not exist, the link appears red (so the &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[like this]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; link is actually rendered [[like this]]). Following such a &amp;quot;redlink&amp;quot; to a missing page (whether or not it is actually red) will enable you to create the page.&lt;br /&gt;
&lt;br /&gt;
To markup any arbitrary string of text (not necessarily a page title) as a link, use a &amp;quot;vertical bar&amp;quot; or &amp;quot;pipe&amp;quot; character, like this: &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[Main Page|our project]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; results in the link [[Main Page|our project]].&lt;br /&gt;
&lt;br /&gt;
The first letter of the link target is usually not case-sensitive, meaning links can be capitalized or not (so How to contribute and how to contribute are equivalent). However, the case of every ''subsequent'' letter must match the target page exactly (so How to contribute and How To Contribute are ''not'' equivalent). Spaces in the page title may be represented as underscores (so How to contribute and How_to_contribute are again equivalent), but using underscores in links will make them visible in the page text (but this can be prevented by using a &amp;quot;pipe&amp;quot;). Please refer to '''rule #2''' above when naming pages to prevent creating duplicates.  &lt;br /&gt;
&lt;br /&gt;
If the page title you are linking to is that of the page you are editing, the result is not a hyperlink at all but simply bold text (for example, on this page the markup &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[Getting started]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; gives the result [[Getting started]]). If you're trying to create a wikilink to the current page, you probably want to link to a specific ''section'' or to an ''anchor'' within the page. You do that by adding a &amp;quot;#&amp;quot; before the section name: &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[#Ground rules]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; will lead to the [[#Ground rules]] section.&lt;br /&gt;
&lt;br /&gt;
Please note that links open by default in the same browser tab.&lt;br /&gt;
&lt;br /&gt;
''==&amp;gt; For more details see [[mediawikiwiki:Help:Links|Help:Links]]''.&lt;br /&gt;
&lt;br /&gt;
====Formatting====&lt;br /&gt;
&lt;br /&gt;
Formatting text to bold, italic, bulleted or numbered lists, tables etc. is most easily done in the Visual Editor. &lt;br /&gt;
&lt;br /&gt;
If you prefer to use the Source Editor, you can format your text by using wiki markup. This consists of normal characters like asterisks, apostrophes or equal signs which have a special function in the wiki, sometimes depending on their position. For example, to format a word in italic, you include it in two pairs of apostrophes like &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;''this''&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
''==&amp;gt; For more details see [[mediawikiwiki:Help:Formatting|Help:Formatting]] and the [[wikipedia:Help:Cheatsheet|Wiki cheat sheet]]''.&lt;br /&gt;
&lt;br /&gt;
====Sections====&lt;br /&gt;
A page can and should be divided into sections, using the section heading syntax. For each page with more than three section headings, a table of contents (TOC) is automatically generated. &lt;br /&gt;
&lt;br /&gt;
Sections are created by creating their headings, as below.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
== Section ==&lt;br /&gt;
=== Subsection ===&lt;br /&gt;
==== Sub-subsection ====&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Please do not use only one equals sign on a side (&amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;= Heading =&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;). This would cause a section heading to be as large as the page's name (title). The maximum number of equals signs is six. Heading names of sections (including subsections) should be unique on a page. Using the same heading more than once on a page causes problems.&lt;br /&gt;
&lt;br /&gt;
Linking to a section within the same page is done with the &amp;lt;nowiki&amp;gt;[[#Section_name]]&amp;lt;/nowiki&amp;gt; syntax. Linking to a section of another page on the same wiki is done by adding the &amp;quot;#&amp;quot; between the page name and the section name: &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[Page_name#Section_name]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;.  &lt;br /&gt;
&lt;br /&gt;
Section headers can be links to other pages: &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[===This section also has it's own page that can be opened via this link===]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;. The recommended practice is to place an excerpt, a summary or an overview of the dedicated page in the section content of the page being linked from.&lt;br /&gt;
&lt;br /&gt;
NEW! Sections can be numbered where necessary. To activate section numbering on a page add this syntax to the page source code (in the source editor): &amp;lt;code&amp;gt;__NUMBEREDHEADINGS__&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==== Categories ====&lt;br /&gt;
In the DE4A wiki we use categories to indicate the status of a page:&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|+Overview of DE4A wiki page categories&lt;br /&gt;
!Category&lt;br /&gt;
!Description&lt;br /&gt;
|-&lt;br /&gt;
|Wip&lt;br /&gt;
|Page labeled as work In progress, not yet ready for review.&lt;br /&gt;
|-&lt;br /&gt;
|Draft&lt;br /&gt;
|Page labelled as a draft, ready for review.&lt;br /&gt;
|-&lt;br /&gt;
|Released&lt;br /&gt;
|A reviewed and finished page.&lt;br /&gt;
|}&lt;br /&gt;
A category label can be added to a page by inserting &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[Category:wip]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; at the top of the page in the Source Editor. &lt;br /&gt;
&lt;br /&gt;
A category page can be created the same way as other wiki pages; just add &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;Category:&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; before the page title. To avoid extra work, try searching within the wiki before creating a new category. The list of all categories can be found in the #List of pages section of the [[Special:SpecialPages#Lists of pages|Special Pages]] page.&lt;br /&gt;
&lt;br /&gt;
== Uploading files ==&lt;br /&gt;
&lt;br /&gt;
=== Files ===&lt;br /&gt;
Files can be uploaded via the Sidebar menu (Tools &amp;gt; Upload File) or while using the Visual Editor (Insert function). Files can be max 2MB in size and permitted file types are png, gif, jpg, jpeg, webp. Other files can be referenced via external links. Appropriate attention should be paid at all times to copyright and confidentiality considerations. &lt;br /&gt;
&lt;br /&gt;
===Images===&lt;br /&gt;
&lt;br /&gt;
The DE4A wiki includes an extension that makes it possible to display clickable image maps. An image map is a list of coordinates in a specific image, which hyperlinks areas of the image to multiple destinations (in contrast to a normal image link, in which the entire area of the image links to a single destination). For example, an application collaboration diagram may have each component or service hyperlinked to further information about that component or service. The intention of an image map is to provide an easy way of linking various parts of an image without dividing the image into separate image files.&lt;br /&gt;
&lt;br /&gt;
== Special pages ==&lt;br /&gt;
Special pages are pages generated by the wiki software on demand for special purposes, usually related to project maintenance. They can be found in the Tools section of the Sidebar (located on the left side of every page). Useful DE4A wiki special pages include:&lt;br /&gt;
&lt;br /&gt;
* [[Special:AllPages|All pages]] &lt;br /&gt;
* [[Special:ListFiles|Files]]&lt;br /&gt;
* [[Special:WantedPages|Wanted pages (red links)]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[https://wiki.de4a.eu/images/6/69/DE4A_-_VC_SSI-based_interaction_pattern_-_User_Story.pdf Wireframe Mock-up]&lt;/div&gt;</summary>
		<author><name>Ictu mavi.cristache</name></author>
	</entry>
	<entry>
		<id>https://wiki.de4a.eu/index.php?title=Getting_started&amp;diff=3779</id>
		<title>Getting started</title>
		<link rel="alternate" type="text/html" href="https://wiki.de4a.eu/index.php?title=Getting_started&amp;diff=3779"/>
		<updated>2021-11-03T12:02:27Z</updated>

		<summary type="html">&lt;p&gt;Ictu mavi.cristache: /* Sections */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;__NUMBEREDHEADINGS__&lt;br /&gt;
&lt;br /&gt;
[[Category:wip]]&lt;br /&gt;
Welcome, new editor of the DE4A documentation wiki! &lt;br /&gt;
&lt;br /&gt;
Before you beging adding content, you can familiarise yourself in on this page with some basic wiki rules and functionalities. All the tips and instructions listed below are also applied on this page, so feel free to copy syntax from the page source as needed. &lt;br /&gt;
&lt;br /&gt;
''==&amp;gt; Additional help is available in the [[wikipedia:Help:Cheatsheet|Wiki cheat sheet]], the [[mediawikiwiki:Special:MyLanguage/Help:Contents|User's Guide]], and the [[mediawikiwiki:Special:MyLanguage/Manual:FAQ|MediaWiki FAQ]].''&lt;br /&gt;
&lt;br /&gt;
==Ground rules==&lt;br /&gt;
'''#1 Create from search.''' When you want to create a new page, start by searching the wiki for existing content. If the search yields no results, you will be offered the option to create a new page. If you do, make sure your search was capitalised in Title Case. Make sure to also search the list of [[Special:WantedPages|Wanted Pages]] to make use of existing links (where possible) and prevent unwittingly duplicating a page name. &lt;br /&gt;
&lt;br /&gt;
'''#2 Page names in Title Case.''' Page names are capitalised using Wikipedia rules. When in doubt, use this [https://titlecaseconverter.com|Title Case Converter] tool to find the correct capitalisation. Different letter cases produce different wiki pages. For example, &amp;quot;[[Reference Interaction Patterns]]&amp;quot; and &amp;quot;[[Interaction patterns|Reference Interaction patterns]]&amp;quot; will lead to two different pages (the former exists on the DE4A wiki, the latter does not and should not, as it does not follow the Title Case capitalisation rule). &lt;br /&gt;
&lt;br /&gt;
'''#3 Ask for help.''' Don't hesitate to contact the [https://wiki.de4a.eu/index.php/Special:ActiveUsers?username=&amp;amp;groups%5B%5D=interface-admin&amp;amp;wpFormIdentifier=specialactiveusers|DE4A WP2 Team] for advice and support when or before adding your content to the wiki. We're here to think along and help.&lt;br /&gt;
&lt;br /&gt;
== Creating and editing pages  ==&lt;br /&gt;
===Starting a new page===&lt;br /&gt;
You can create a new page from a search or from a red link. In both cases, please observe the Title Case capitalisation rule (#2) above for naming the page. '''Page names cannot be edited anymore once created!''' &lt;br /&gt;
&lt;br /&gt;
''==&amp;gt; For more details see [[mediawikiwiki:Help:Starting_a_new_page|Help:Starting a new page.]]'' &lt;br /&gt;
===Editing===&lt;br /&gt;
You can edit the contents of a page with the Visual Editor or the Source Editor. The Visual Editor provides a direct visual way to edit pages based on the &amp;quot;what you see is what you get&amp;quot; principle. It contains a handy page searching function when inserting links. Visual editing is chosen by clicking the &amp;lt;kbd&amp;gt;Edit&amp;lt;/kbd&amp;gt; tab at the top of a page (or on a section-edit link). The Source Editor can be used for additional functionality with such things as categories, hyperlinks, tables and columns, footnotes, inline citation, special characters and so on. You can access the Source Editor by clicking the &amp;lt;kbd&amp;gt;Edit source&amp;lt;/kbd&amp;gt; tab at the top of a page (or on a section-edit link).  &lt;br /&gt;
&lt;br /&gt;
''==&amp;gt; For more help with the editing interfaces see [[mediawikiwiki:Help:Editing_pages|Help:Editing_pages]] and the [[mediawikiwiki:Help:VisualEditor/User_guide|Visual Editor User Guide]].''  &lt;br /&gt;
&lt;br /&gt;
====Links====&lt;br /&gt;
The most relevant two types of hypertext links in this wiki are internal links to other pages in the same wiki (commonly called &amp;quot;wikilinks&amp;quot;) and external links to pages at other websites. &lt;br /&gt;
&lt;br /&gt;
To create a so-called internal link to a page on the same wiki (a &amp;quot;wikilink&amp;quot;), use double square brackets wiki markup, &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[like this]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;. When you preview or save your changes, you will see a link that can be followed to the target page. If the page exists the link is displayed in blue; if the page does not exist, the link appears red (so the &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[like this]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; link is actually rendered [[like this]]). Following such a &amp;quot;redlink&amp;quot; to a missing page (whether or not it is actually red) will enable you to create the page.&lt;br /&gt;
&lt;br /&gt;
To markup any arbitrary string of text (not necessarily a page title) as a link, use a &amp;quot;vertical bar&amp;quot; or &amp;quot;pipe&amp;quot; character, like this: &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[Main Page|our project]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; results in the link [[Main Page|our project]].&lt;br /&gt;
&lt;br /&gt;
The first letter of the link target is usually not case-sensitive, meaning links can be capitalized or not (so How to contribute and how to contribute are equivalent). However, the case of every ''subsequent'' letter must match the target page exactly (so How to contribute and How To Contribute are ''not'' equivalent). Spaces in the page title may be represented as underscores (so How to contribute and How_to_contribute are again equivalent), but using underscores in links will make them visible in the page text (but this can be prevented by using a &amp;quot;pipe&amp;quot;). Please refer to '''rule #2''' above when naming pages to prevent creating duplicates.  &lt;br /&gt;
&lt;br /&gt;
If the page title you are linking to is that of the page you are editing, the result is not a hyperlink at all but simply bold text (for example, on this page the markup &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[Getting started]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; gives the result [[Getting started]]). If you're trying to create a wikilink to the current page, you probably want to link to a specific ''section'' or to an ''anchor'' within the page. You do that by adding a &amp;quot;#&amp;quot; before the section name: &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[#Ground rules]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; will lead to the [[#Ground rules]] section.&lt;br /&gt;
&lt;br /&gt;
Please note that links open by default in the same browser tab.&lt;br /&gt;
&lt;br /&gt;
''==&amp;gt; For more details see [[mediawikiwiki:Help:Links|Help:Links]]''.&lt;br /&gt;
&lt;br /&gt;
====Formatting====&lt;br /&gt;
&lt;br /&gt;
Formatting text to bold, italic, bulleted or numbered lists, tables etc. is most easily done in the Visual Editor. &lt;br /&gt;
&lt;br /&gt;
If you prefer to use the Source Editor, you can format your text by using wiki markup. This consists of normal characters like asterisks, apostrophes or equal signs which have a special function in the wiki, sometimes depending on their position. For example, to format a word in italic, you include it in two pairs of apostrophes like &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;''this''&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
''==&amp;gt; For more details see [[mediawikiwiki:Help:Formatting|Help:Formatting]] and the [[wikipedia:Help:Cheatsheet|Wiki cheat sheet]]''.&lt;br /&gt;
&lt;br /&gt;
====Sections====&lt;br /&gt;
A page can and should be divided into sections, using the section heading syntax. For each page with more than three section headings, a table of contents (TOC) is automatically generated. &lt;br /&gt;
&lt;br /&gt;
Sections are created by creating their headings, as below.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
== Section ==&lt;br /&gt;
=== Subsection ===&lt;br /&gt;
==== Sub-subsection ====&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Please do not use only one equals sign on a side (&amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;= Heading =&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;). This would cause a section heading to be as large as the page's name (title). The maximum number of equals signs is six. Heading names of sections (including subsections) should be unique on a page. Using the same heading more than once on a page causes problems.&lt;br /&gt;
&lt;br /&gt;
Linking to a section within the same page is done with the &amp;lt;nowiki&amp;gt;[[#Section_name]]&amp;lt;/nowiki&amp;gt; syntax. Linking to a section of another page on the same wiki is done by adding the &amp;quot;#&amp;quot; between the page name and the section name: &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[Page_name#Section_name]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;.  &lt;br /&gt;
&lt;br /&gt;
Section headers can be links to other pages: &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[===This section also has it's own page that can be opened via this link===]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;. The recommended practice is to place an excerpt, a summary or an overview of the dedicated page in the section content of the page being linked from.&lt;br /&gt;
&lt;br /&gt;
NEW! Sections can be numbered where necessary. To activate section numbering on a page add this syntax to the page source code (in the source editor): &amp;lt;pre&amp;gt;__NUMBEREDHEADINGS__&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==== Categories ====&lt;br /&gt;
In the DE4A wiki we use categories to indicate the status of a page:&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|+Overview of DE4A wiki page categories&lt;br /&gt;
!Category&lt;br /&gt;
!Description&lt;br /&gt;
|-&lt;br /&gt;
|Wip&lt;br /&gt;
|Page labeled as work In progress, not yet ready for review.&lt;br /&gt;
|-&lt;br /&gt;
|Draft&lt;br /&gt;
|Page labelled as a draft, ready for review.&lt;br /&gt;
|-&lt;br /&gt;
|Released&lt;br /&gt;
|A reviewed and finished page.&lt;br /&gt;
|}&lt;br /&gt;
A category label can be added to a page by inserting &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[Category:wip]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; at the top of the page in the Source Editor. &lt;br /&gt;
&lt;br /&gt;
A category page can be created the same way as other wiki pages; just add &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;Category:&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; before the page title. To avoid extra work, try searching within the wiki before creating a new category. The list of all categories can be found in the #List of pages section of the [[Special:SpecialPages#Lists of pages|Special Pages]] page.&lt;br /&gt;
&lt;br /&gt;
== Uploading files ==&lt;br /&gt;
&lt;br /&gt;
=== Files ===&lt;br /&gt;
Files can be uploaded via the Sidebar menu (Tools &amp;gt; Upload File) or while using the Visual Editor (Insert function). Files can be max 2MB in size and permitted file types are png, gif, jpg, jpeg, webp. Other files can be referenced via external links. Appropriate attention should be paid at all times to copyright and confidentiality considerations. &lt;br /&gt;
&lt;br /&gt;
===Images===&lt;br /&gt;
&lt;br /&gt;
The DE4A wiki includes an extension that makes it possible to display clickable image maps. An image map is a list of coordinates in a specific image, which hyperlinks areas of the image to multiple destinations (in contrast to a normal image link, in which the entire area of the image links to a single destination). For example, an application collaboration diagram may have each component or service hyperlinked to further information about that component or service. The intention of an image map is to provide an easy way of linking various parts of an image without dividing the image into separate image files.&lt;br /&gt;
&lt;br /&gt;
== Special pages ==&lt;br /&gt;
Special pages are pages generated by the wiki software on demand for special purposes, usually related to project maintenance. They can be found in the Tools section of the Sidebar (located on the left side of every page). Useful DE4A wiki special pages include:&lt;br /&gt;
&lt;br /&gt;
* [[Special:AllPages|All pages]] &lt;br /&gt;
* [[Special:ListFiles|Files]]&lt;br /&gt;
* [[Special:WantedPages|Wanted pages (red links)]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[https://wiki.de4a.eu/images/6/69/DE4A_-_VC_SSI-based_interaction_pattern_-_User_Story.pdf Wireframe Mock-up]&lt;/div&gt;</summary>
		<author><name>Ictu mavi.cristache</name></author>
	</entry>
	<entry>
		<id>https://wiki.de4a.eu/index.php?title=Getting_started&amp;diff=3778</id>
		<title>Getting started</title>
		<link rel="alternate" type="text/html" href="https://wiki.de4a.eu/index.php?title=Getting_started&amp;diff=3778"/>
		<updated>2021-11-03T12:01:38Z</updated>

		<summary type="html">&lt;p&gt;Ictu mavi.cristache: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;__NUMBEREDHEADINGS__&lt;br /&gt;
&lt;br /&gt;
[[Category:wip]]&lt;br /&gt;
Welcome, new editor of the DE4A documentation wiki! &lt;br /&gt;
&lt;br /&gt;
Before you beging adding content, you can familiarise yourself in on this page with some basic wiki rules and functionalities. All the tips and instructions listed below are also applied on this page, so feel free to copy syntax from the page source as needed. &lt;br /&gt;
&lt;br /&gt;
''==&amp;gt; Additional help is available in the [[wikipedia:Help:Cheatsheet|Wiki cheat sheet]], the [[mediawikiwiki:Special:MyLanguage/Help:Contents|User's Guide]], and the [[mediawikiwiki:Special:MyLanguage/Manual:FAQ|MediaWiki FAQ]].''&lt;br /&gt;
&lt;br /&gt;
==Ground rules==&lt;br /&gt;
'''#1 Create from search.''' When you want to create a new page, start by searching the wiki for existing content. If the search yields no results, you will be offered the option to create a new page. If you do, make sure your search was capitalised in Title Case. Make sure to also search the list of [[Special:WantedPages|Wanted Pages]] to make use of existing links (where possible) and prevent unwittingly duplicating a page name. &lt;br /&gt;
&lt;br /&gt;
'''#2 Page names in Title Case.''' Page names are capitalised using Wikipedia rules. When in doubt, use this [https://titlecaseconverter.com|Title Case Converter] tool to find the correct capitalisation. Different letter cases produce different wiki pages. For example, &amp;quot;[[Reference Interaction Patterns]]&amp;quot; and &amp;quot;[[Interaction patterns|Reference Interaction patterns]]&amp;quot; will lead to two different pages (the former exists on the DE4A wiki, the latter does not and should not, as it does not follow the Title Case capitalisation rule). &lt;br /&gt;
&lt;br /&gt;
'''#3 Ask for help.''' Don't hesitate to contact the [https://wiki.de4a.eu/index.php/Special:ActiveUsers?username=&amp;amp;groups%5B%5D=interface-admin&amp;amp;wpFormIdentifier=specialactiveusers|DE4A WP2 Team] for advice and support when or before adding your content to the wiki. We're here to think along and help.&lt;br /&gt;
&lt;br /&gt;
== Creating and editing pages  ==&lt;br /&gt;
===Starting a new page===&lt;br /&gt;
You can create a new page from a search or from a red link. In both cases, please observe the Title Case capitalisation rule (#2) above for naming the page. '''Page names cannot be edited anymore once created!''' &lt;br /&gt;
&lt;br /&gt;
''==&amp;gt; For more details see [[mediawikiwiki:Help:Starting_a_new_page|Help:Starting a new page.]]'' &lt;br /&gt;
===Editing===&lt;br /&gt;
You can edit the contents of a page with the Visual Editor or the Source Editor. The Visual Editor provides a direct visual way to edit pages based on the &amp;quot;what you see is what you get&amp;quot; principle. It contains a handy page searching function when inserting links. Visual editing is chosen by clicking the &amp;lt;kbd&amp;gt;Edit&amp;lt;/kbd&amp;gt; tab at the top of a page (or on a section-edit link). The Source Editor can be used for additional functionality with such things as categories, hyperlinks, tables and columns, footnotes, inline citation, special characters and so on. You can access the Source Editor by clicking the &amp;lt;kbd&amp;gt;Edit source&amp;lt;/kbd&amp;gt; tab at the top of a page (or on a section-edit link).  &lt;br /&gt;
&lt;br /&gt;
''==&amp;gt; For more help with the editing interfaces see [[mediawikiwiki:Help:Editing_pages|Help:Editing_pages]] and the [[mediawikiwiki:Help:VisualEditor/User_guide|Visual Editor User Guide]].''  &lt;br /&gt;
&lt;br /&gt;
====Links====&lt;br /&gt;
The most relevant two types of hypertext links in this wiki are internal links to other pages in the same wiki (commonly called &amp;quot;wikilinks&amp;quot;) and external links to pages at other websites. &lt;br /&gt;
&lt;br /&gt;
To create a so-called internal link to a page on the same wiki (a &amp;quot;wikilink&amp;quot;), use double square brackets wiki markup, &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[like this]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;. When you preview or save your changes, you will see a link that can be followed to the target page. If the page exists the link is displayed in blue; if the page does not exist, the link appears red (so the &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[like this]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; link is actually rendered [[like this]]). Following such a &amp;quot;redlink&amp;quot; to a missing page (whether or not it is actually red) will enable you to create the page.&lt;br /&gt;
&lt;br /&gt;
To markup any arbitrary string of text (not necessarily a page title) as a link, use a &amp;quot;vertical bar&amp;quot; or &amp;quot;pipe&amp;quot; character, like this: &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[Main Page|our project]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; results in the link [[Main Page|our project]].&lt;br /&gt;
&lt;br /&gt;
The first letter of the link target is usually not case-sensitive, meaning links can be capitalized or not (so How to contribute and how to contribute are equivalent). However, the case of every ''subsequent'' letter must match the target page exactly (so How to contribute and How To Contribute are ''not'' equivalent). Spaces in the page title may be represented as underscores (so How to contribute and How_to_contribute are again equivalent), but using underscores in links will make them visible in the page text (but this can be prevented by using a &amp;quot;pipe&amp;quot;). Please refer to '''rule #2''' above when naming pages to prevent creating duplicates.  &lt;br /&gt;
&lt;br /&gt;
If the page title you are linking to is that of the page you are editing, the result is not a hyperlink at all but simply bold text (for example, on this page the markup &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[Getting started]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; gives the result [[Getting started]]). If you're trying to create a wikilink to the current page, you probably want to link to a specific ''section'' or to an ''anchor'' within the page. You do that by adding a &amp;quot;#&amp;quot; before the section name: &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[#Ground rules]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; will lead to the [[#Ground rules]] section.&lt;br /&gt;
&lt;br /&gt;
Please note that links open by default in the same browser tab.&lt;br /&gt;
&lt;br /&gt;
''==&amp;gt; For more details see [[mediawikiwiki:Help:Links|Help:Links]]''.&lt;br /&gt;
&lt;br /&gt;
====Formatting====&lt;br /&gt;
&lt;br /&gt;
Formatting text to bold, italic, bulleted or numbered lists, tables etc. is most easily done in the Visual Editor. &lt;br /&gt;
&lt;br /&gt;
If you prefer to use the Source Editor, you can format your text by using wiki markup. This consists of normal characters like asterisks, apostrophes or equal signs which have a special function in the wiki, sometimes depending on their position. For example, to format a word in italic, you include it in two pairs of apostrophes like &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;''this''&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
''==&amp;gt; For more details see [[mediawikiwiki:Help:Formatting|Help:Formatting]] and the [[wikipedia:Help:Cheatsheet|Wiki cheat sheet]]''.&lt;br /&gt;
&lt;br /&gt;
====Sections====&lt;br /&gt;
A page can and should be divided into sections, using the section heading syntax. For each page with more than three section headings, a table of contents (TOC) is automatically generated. &lt;br /&gt;
&lt;br /&gt;
Sections are created by creating their headings, as below.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
== Section ==&lt;br /&gt;
=== Subsection ===&lt;br /&gt;
==== Sub-subsection ====&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Please do not use only one equals sign on a side (&amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;= Heading =&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;). This would cause a section heading to be as large as the page's name (title). The maximum number of equals signs is six. Heading names of sections (including subsections) should be unique on a page. Using the same heading more than once on a page causes problems.&lt;br /&gt;
&lt;br /&gt;
Linking to a section within the same page is done with the &amp;lt;nowiki&amp;gt;[[#Section_name]]&amp;lt;/nowiki&amp;gt; syntax. Linking to a section of another page on the same wiki is done by adding the &amp;quot;#&amp;quot; between the page name and the section name: &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[Page_name#Section_name]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;.  &lt;br /&gt;
&lt;br /&gt;
Section headers can be links to other pages: &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[===This section also has it's own page that can be opened via this link===]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;. The recommended practice is to place an excerpt, a summary or an overview of the dedicated page in the section content of the page being linked from.&lt;br /&gt;
&lt;br /&gt;
NEW! Sections can be numbered where necessary. To activate section numbering on a page add this syntax to the page source code (in the source editor): &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;__NUMBEREDHEADINGS__&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==== Categories ====&lt;br /&gt;
In the DE4A wiki we use categories to indicate the status of a page:&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|+Overview of DE4A wiki page categories&lt;br /&gt;
!Category&lt;br /&gt;
!Description&lt;br /&gt;
|-&lt;br /&gt;
|Wip&lt;br /&gt;
|Page labeled as work In progress, not yet ready for review.&lt;br /&gt;
|-&lt;br /&gt;
|Draft&lt;br /&gt;
|Page labelled as a draft, ready for review.&lt;br /&gt;
|-&lt;br /&gt;
|Released&lt;br /&gt;
|A reviewed and finished page.&lt;br /&gt;
|}&lt;br /&gt;
A category label can be added to a page by inserting &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[Category:wip]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; at the top of the page in the Source Editor. &lt;br /&gt;
&lt;br /&gt;
A category page can be created the same way as other wiki pages; just add &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;Category:&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; before the page title. To avoid extra work, try searching within the wiki before creating a new category. The list of all categories can be found in the #List of pages section of the [[Special:SpecialPages#Lists of pages|Special Pages]] page.&lt;br /&gt;
&lt;br /&gt;
== Uploading files ==&lt;br /&gt;
&lt;br /&gt;
=== Files ===&lt;br /&gt;
Files can be uploaded via the Sidebar menu (Tools &amp;gt; Upload File) or while using the Visual Editor (Insert function). Files can be max 2MB in size and permitted file types are png, gif, jpg, jpeg, webp. Other files can be referenced via external links. Appropriate attention should be paid at all times to copyright and confidentiality considerations. &lt;br /&gt;
&lt;br /&gt;
===Images===&lt;br /&gt;
&lt;br /&gt;
The DE4A wiki includes an extension that makes it possible to display clickable image maps. An image map is a list of coordinates in a specific image, which hyperlinks areas of the image to multiple destinations (in contrast to a normal image link, in which the entire area of the image links to a single destination). For example, an application collaboration diagram may have each component or service hyperlinked to further information about that component or service. The intention of an image map is to provide an easy way of linking various parts of an image without dividing the image into separate image files.&lt;br /&gt;
&lt;br /&gt;
== Special pages ==&lt;br /&gt;
Special pages are pages generated by the wiki software on demand for special purposes, usually related to project maintenance. They can be found in the Tools section of the Sidebar (located on the left side of every page). Useful DE4A wiki special pages include:&lt;br /&gt;
&lt;br /&gt;
* [[Special:AllPages|All pages]] &lt;br /&gt;
* [[Special:ListFiles|Files]]&lt;br /&gt;
* [[Special:WantedPages|Wanted pages (red links)]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[https://wiki.de4a.eu/images/6/69/DE4A_-_VC_SSI-based_interaction_pattern_-_User_Story.pdf Wireframe Mock-up]&lt;/div&gt;</summary>
		<author><name>Ictu mavi.cristache</name></author>
	</entry>
	<entry>
		<id>https://wiki.de4a.eu/index.php?title=Getting_started&amp;diff=3777</id>
		<title>Getting started</title>
		<link rel="alternate" type="text/html" href="https://wiki.de4a.eu/index.php?title=Getting_started&amp;diff=3777"/>
		<updated>2021-11-03T12:01:07Z</updated>

		<summary type="html">&lt;p&gt;Ictu mavi.cristache: /* Sections */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;__NUMBEREDHEADINGS__&lt;br /&gt;
&lt;br /&gt;
[[Category:wip]]&lt;br /&gt;
Welcome, new editor of the DE4A documentation wiki! &lt;br /&gt;
&lt;br /&gt;
Before you beging adding content, you can familiarise yourself in on this page with some basic wiki rules and functionalities. All the tips and instructions listed below are also applied on this page, so feel free to copy syntax from the page source as needed. &lt;br /&gt;
&lt;br /&gt;
''==&amp;gt; Additional help is available in the [[wikipedia:Help:Cheatsheet|Wiki cheat sheet]], the [[mediawikiwiki:Special:MyLanguage/Help:Contents|User's Guide]], and the [[mediawikiwiki:Special:MyLanguage/Manual:FAQ|MediaWiki FAQ]].''&lt;br /&gt;
&lt;br /&gt;
==Ground rules==&lt;br /&gt;
'''#1 Create from search.''' When you want to create a new page, start by searching the wiki for existing content. If the search yields no results, you will be offered the option to create a new page. If you do, make sure your search was capitalised in Title Case. Make sure to also search the list of [[Special:WantedPages|Wanted Pages]] to make use of existing links (where possible) and prevent unwittingly duplicating a page name. &lt;br /&gt;
&lt;br /&gt;
'''#2 Page names in Title Case.''' Page names are capitalised using Wikipedia rules. When in doubt, use this [https://titlecaseconverter.com|Title Case Converter] tool to find the correct capitalisation. Different letter cases produce different wiki pages. For example, &amp;quot;[[Reference Interaction Patterns]]&amp;quot; and &amp;quot;[[Interaction patterns|Reference Interaction patterns]]&amp;quot; will lead to two different pages (the former exists on the DE4A wiki, the latter does not and should not, as it does not follow the Title Case capitalisation rule). &lt;br /&gt;
&lt;br /&gt;
'''#3 Ask for help.''' Don't hesitate to contact the [https://wiki.de4a.eu/index.php/Special:ActiveUsers?username=&amp;amp;groups%5B%5D=interface-admin&amp;amp;wpFormIdentifier=specialactiveusers|DE4A WP2 Team] for advice and support when or before adding your content to the wiki. We're here to think along and help.&lt;br /&gt;
&lt;br /&gt;
== Creating and editing pages  ==&lt;br /&gt;
===Starting a new page===&lt;br /&gt;
You can create a new page from a search or from a red link. In both cases, please observe the Title Case capitalisation rule (#2) above for naming the page. '''Page names cannot be edited anymore once created!''' &lt;br /&gt;
&lt;br /&gt;
''==&amp;gt; For more details see [[mediawikiwiki:Help:Starting_a_new_page|Help:Starting a new page.]]'' &lt;br /&gt;
===Editing===&lt;br /&gt;
You can edit the contents of a page with the Visual Editor or the Source Editor. The Visual Editor provides a direct visual way to edit pages based on the &amp;quot;what you see is what you get&amp;quot; principle. It contains a handy page searching function when inserting links. Visual editing is chosen by clicking the &amp;lt;kbd&amp;gt;Edit&amp;lt;/kbd&amp;gt; tab at the top of a page (or on a section-edit link). The Source Editor can be used for additional functionality with such things as categories, hyperlinks, tables and columns, footnotes, inline citation, special characters and so on. You can access the Source Editor by clicking the &amp;lt;kbd&amp;gt;Edit source&amp;lt;/kbd&amp;gt; tab at the top of a page (or on a section-edit link).  &lt;br /&gt;
&lt;br /&gt;
''==&amp;gt; For more help with the editing interfaces see [[mediawikiwiki:Help:Editing_pages|Help:Editing_pages]] and the [[mediawikiwiki:Help:VisualEditor/User_guide|Visual Editor User Guide]].''  &lt;br /&gt;
&lt;br /&gt;
====Links====&lt;br /&gt;
The most relevant two types of hypertext links in this wiki are internal links to other pages in the same wiki (commonly called &amp;quot;wikilinks&amp;quot;) and external links to pages at other websites. &lt;br /&gt;
&lt;br /&gt;
To create a so-called internal link to a page on the same wiki (a &amp;quot;wikilink&amp;quot;), use double square brackets wiki markup, &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[like this]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;. When you preview or save your changes, you will see a link that can be followed to the target page. If the page exists the link is displayed in blue; if the page does not exist, the link appears red (so the &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[like this]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; link is actually rendered [[like this]]). Following such a &amp;quot;redlink&amp;quot; to a missing page (whether or not it is actually red) will enable you to create the page.&lt;br /&gt;
&lt;br /&gt;
To markup any arbitrary string of text (not necessarily a page title) as a link, use a &amp;quot;vertical bar&amp;quot; or &amp;quot;pipe&amp;quot; character, like this: &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[Main Page|our project]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; results in the link [[Main Page|our project]].&lt;br /&gt;
&lt;br /&gt;
The first letter of the link target is usually not case-sensitive, meaning links can be capitalized or not (so How to contribute and how to contribute are equivalent). However, the case of every ''subsequent'' letter must match the target page exactly (so How to contribute and How To Contribute are ''not'' equivalent). Spaces in the page title may be represented as underscores (so How to contribute and How_to_contribute are again equivalent), but using underscores in links will make them visible in the page text (but this can be prevented by using a &amp;quot;pipe&amp;quot;). Please refer to '''rule #2''' above when naming pages to prevent creating duplicates.  &lt;br /&gt;
&lt;br /&gt;
If the page title you are linking to is that of the page you are editing, the result is not a hyperlink at all but simply bold text (for example, on this page the markup &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[Getting started]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; gives the result [[Getting started]]). If you're trying to create a wikilink to the current page, you probably want to link to a specific ''section'' or to an ''anchor'' within the page. You do that by adding a &amp;quot;#&amp;quot; before the section name: &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[#Ground rules]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; will lead to the [[#Ground rules]] section.&lt;br /&gt;
&lt;br /&gt;
Please note that links open by default in the same browser tab.&lt;br /&gt;
&lt;br /&gt;
''==&amp;gt; For more details see [[mediawikiwiki:Help:Links|Help:Links]]''.&lt;br /&gt;
&lt;br /&gt;
====Formatting====&lt;br /&gt;
&lt;br /&gt;
Formatting text to bold, italic, bulleted or numbered lists, tables etc. is most easily done in the Visual Editor. &lt;br /&gt;
&lt;br /&gt;
If you prefer to use the Source Editor, you can format your text by using wiki markup. This consists of normal characters like asterisks, apostrophes or equal signs which have a special function in the wiki, sometimes depending on their position. For example, to format a word in italic, you include it in two pairs of apostrophes like &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;''this''&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
''==&amp;gt; For more details see [[mediawikiwiki:Help:Formatting|Help:Formatting]] and the [[wikipedia:Help:Cheatsheet|Wiki cheat sheet]]''.&lt;br /&gt;
&lt;br /&gt;
====Sections====&lt;br /&gt;
A page can and should be divided into sections, using the section heading syntax. For each page with more than three section headings, a table of contents (TOC) is automatically generated. &lt;br /&gt;
&lt;br /&gt;
Sections are created by creating their headings, as below.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
== Section ==&lt;br /&gt;
=== Subsection ===&lt;br /&gt;
==== Sub-subsection ====&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Please do not use only one equals sign on a side (&amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;= Heading =&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;). This would cause a section heading to be as large as the page's name (title). The maximum number of equals signs is six. Heading names of sections (including subsections) should be unique on a page. Using the same heading more than once on a page causes problems.&lt;br /&gt;
&lt;br /&gt;
Linking to a section within the same page is done with the &amp;lt;nowiki&amp;gt;[[#Section_name]]&amp;lt;/nowiki&amp;gt; syntax. Linking to a section of another page on the same wiki is done by adding the &amp;quot;#&amp;quot; between the page name and the section name: &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[Page_name#Section_name]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;.  &lt;br /&gt;
&lt;br /&gt;
Section headers can be links to other pages: &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[===This section also has it's own page that can be opened via this link===]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;. The recommended practice is to place an excerpt, a summary or an overview of the dedicated page in the section content of the page being linked from.&lt;br /&gt;
&lt;br /&gt;
NEW! Sections can be numbered where necessary. To activate section numbering on a page add this syntax to the page source code (in the source editor): (&amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;= Heading =&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;)&lt;br /&gt;
&lt;br /&gt;
==== Categories ====&lt;br /&gt;
In the DE4A wiki we use categories to indicate the status of a page:&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|+Overview of DE4A wiki page categories&lt;br /&gt;
!Category&lt;br /&gt;
!Description&lt;br /&gt;
|-&lt;br /&gt;
|Wip&lt;br /&gt;
|Page labeled as work In progress, not yet ready for review.&lt;br /&gt;
|-&lt;br /&gt;
|Draft&lt;br /&gt;
|Page labelled as a draft, ready for review.&lt;br /&gt;
|-&lt;br /&gt;
|Released&lt;br /&gt;
|A reviewed and finished page.&lt;br /&gt;
|}&lt;br /&gt;
A category label can be added to a page by inserting &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[Category:wip]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; at the top of the page in the Source Editor. &lt;br /&gt;
&lt;br /&gt;
A category page can be created the same way as other wiki pages; just add &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;Category:&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; before the page title. To avoid extra work, try searching within the wiki before creating a new category. The list of all categories can be found in the #List of pages section of the [[Special:SpecialPages#Lists of pages|Special Pages]] page.&lt;br /&gt;
&lt;br /&gt;
== Uploading files ==&lt;br /&gt;
&lt;br /&gt;
=== Files ===&lt;br /&gt;
Files can be uploaded via the Sidebar menu (Tools &amp;gt; Upload File) or while using the Visual Editor (Insert function). Files can be max 2MB in size and permitted file types are png, gif, jpg, jpeg, webp. Other files can be referenced via external links. Appropriate attention should be paid at all times to copyright and confidentiality considerations. &lt;br /&gt;
&lt;br /&gt;
===Images===&lt;br /&gt;
&lt;br /&gt;
The DE4A wiki includes an extension that makes it possible to display clickable image maps. An image map is a list of coordinates in a specific image, which hyperlinks areas of the image to multiple destinations (in contrast to a normal image link, in which the entire area of the image links to a single destination). For example, an application collaboration diagram may have each component or service hyperlinked to further information about that component or service. The intention of an image map is to provide an easy way of linking various parts of an image without dividing the image into separate image files.&lt;br /&gt;
&lt;br /&gt;
== Special pages ==&lt;br /&gt;
Special pages are pages generated by the wiki software on demand for special purposes, usually related to project maintenance. They can be found in the Tools section of the Sidebar (located on the left side of every page). Useful DE4A wiki special pages include:&lt;br /&gt;
&lt;br /&gt;
* [[Special:AllPages|All pages]] &lt;br /&gt;
* [[Special:ListFiles|Files]]&lt;br /&gt;
* [[Special:WantedPages|Wanted pages (red links)]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[https://wiki.de4a.eu/images/6/69/DE4A_-_VC_SSI-based_interaction_pattern_-_User_Story.pdf Wireframe Mock-up]&lt;/div&gt;</summary>
		<author><name>Ictu mavi.cristache</name></author>
	</entry>
	<entry>
		<id>https://wiki.de4a.eu/index.php?title=Getting_started&amp;diff=3776</id>
		<title>Getting started</title>
		<link rel="alternate" type="text/html" href="https://wiki.de4a.eu/index.php?title=Getting_started&amp;diff=3776"/>
		<updated>2021-11-03T12:00:11Z</updated>

		<summary type="html">&lt;p&gt;Ictu mavi.cristache: /* Sections */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;__NUMBEREDHEADINGS__&lt;br /&gt;
&lt;br /&gt;
[[Category:wip]]&lt;br /&gt;
Welcome, new editor of the DE4A documentation wiki! &lt;br /&gt;
&lt;br /&gt;
Before you beging adding content, you can familiarise yourself in on this page with some basic wiki rules and functionalities. All the tips and instructions listed below are also applied on this page, so feel free to copy syntax from the page source as needed. &lt;br /&gt;
&lt;br /&gt;
''==&amp;gt; Additional help is available in the [[wikipedia:Help:Cheatsheet|Wiki cheat sheet]], the [[mediawikiwiki:Special:MyLanguage/Help:Contents|User's Guide]], and the [[mediawikiwiki:Special:MyLanguage/Manual:FAQ|MediaWiki FAQ]].''&lt;br /&gt;
&lt;br /&gt;
==Ground rules==&lt;br /&gt;
'''#1 Create from search.''' When you want to create a new page, start by searching the wiki for existing content. If the search yields no results, you will be offered the option to create a new page. If you do, make sure your search was capitalised in Title Case. Make sure to also search the list of [[Special:WantedPages|Wanted Pages]] to make use of existing links (where possible) and prevent unwittingly duplicating a page name. &lt;br /&gt;
&lt;br /&gt;
'''#2 Page names in Title Case.''' Page names are capitalised using Wikipedia rules. When in doubt, use this [https://titlecaseconverter.com|Title Case Converter] tool to find the correct capitalisation. Different letter cases produce different wiki pages. For example, &amp;quot;[[Reference Interaction Patterns]]&amp;quot; and &amp;quot;[[Interaction patterns|Reference Interaction patterns]]&amp;quot; will lead to two different pages (the former exists on the DE4A wiki, the latter does not and should not, as it does not follow the Title Case capitalisation rule). &lt;br /&gt;
&lt;br /&gt;
'''#3 Ask for help.''' Don't hesitate to contact the [https://wiki.de4a.eu/index.php/Special:ActiveUsers?username=&amp;amp;groups%5B%5D=interface-admin&amp;amp;wpFormIdentifier=specialactiveusers|DE4A WP2 Team] for advice and support when or before adding your content to the wiki. We're here to think along and help.&lt;br /&gt;
&lt;br /&gt;
== Creating and editing pages  ==&lt;br /&gt;
===Starting a new page===&lt;br /&gt;
You can create a new page from a search or from a red link. In both cases, please observe the Title Case capitalisation rule (#2) above for naming the page. '''Page names cannot be edited anymore once created!''' &lt;br /&gt;
&lt;br /&gt;
''==&amp;gt; For more details see [[mediawikiwiki:Help:Starting_a_new_page|Help:Starting a new page.]]'' &lt;br /&gt;
===Editing===&lt;br /&gt;
You can edit the contents of a page with the Visual Editor or the Source Editor. The Visual Editor provides a direct visual way to edit pages based on the &amp;quot;what you see is what you get&amp;quot; principle. It contains a handy page searching function when inserting links. Visual editing is chosen by clicking the &amp;lt;kbd&amp;gt;Edit&amp;lt;/kbd&amp;gt; tab at the top of a page (or on a section-edit link). The Source Editor can be used for additional functionality with such things as categories, hyperlinks, tables and columns, footnotes, inline citation, special characters and so on. You can access the Source Editor by clicking the &amp;lt;kbd&amp;gt;Edit source&amp;lt;/kbd&amp;gt; tab at the top of a page (or on a section-edit link).  &lt;br /&gt;
&lt;br /&gt;
''==&amp;gt; For more help with the editing interfaces see [[mediawikiwiki:Help:Editing_pages|Help:Editing_pages]] and the [[mediawikiwiki:Help:VisualEditor/User_guide|Visual Editor User Guide]].''  &lt;br /&gt;
&lt;br /&gt;
====Links====&lt;br /&gt;
The most relevant two types of hypertext links in this wiki are internal links to other pages in the same wiki (commonly called &amp;quot;wikilinks&amp;quot;) and external links to pages at other websites. &lt;br /&gt;
&lt;br /&gt;
To create a so-called internal link to a page on the same wiki (a &amp;quot;wikilink&amp;quot;), use double square brackets wiki markup, &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[like this]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;. When you preview or save your changes, you will see a link that can be followed to the target page. If the page exists the link is displayed in blue; if the page does not exist, the link appears red (so the &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[like this]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; link is actually rendered [[like this]]). Following such a &amp;quot;redlink&amp;quot; to a missing page (whether or not it is actually red) will enable you to create the page.&lt;br /&gt;
&lt;br /&gt;
To markup any arbitrary string of text (not necessarily a page title) as a link, use a &amp;quot;vertical bar&amp;quot; or &amp;quot;pipe&amp;quot; character, like this: &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[Main Page|our project]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; results in the link [[Main Page|our project]].&lt;br /&gt;
&lt;br /&gt;
The first letter of the link target is usually not case-sensitive, meaning links can be capitalized or not (so How to contribute and how to contribute are equivalent). However, the case of every ''subsequent'' letter must match the target page exactly (so How to contribute and How To Contribute are ''not'' equivalent). Spaces in the page title may be represented as underscores (so How to contribute and How_to_contribute are again equivalent), but using underscores in links will make them visible in the page text (but this can be prevented by using a &amp;quot;pipe&amp;quot;). Please refer to '''rule #2''' above when naming pages to prevent creating duplicates.  &lt;br /&gt;
&lt;br /&gt;
If the page title you are linking to is that of the page you are editing, the result is not a hyperlink at all but simply bold text (for example, on this page the markup &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[Getting started]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; gives the result [[Getting started]]). If you're trying to create a wikilink to the current page, you probably want to link to a specific ''section'' or to an ''anchor'' within the page. You do that by adding a &amp;quot;#&amp;quot; before the section name: &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[#Ground rules]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; will lead to the [[#Ground rules]] section.&lt;br /&gt;
&lt;br /&gt;
Please note that links open by default in the same browser tab.&lt;br /&gt;
&lt;br /&gt;
''==&amp;gt; For more details see [[mediawikiwiki:Help:Links|Help:Links]]''.&lt;br /&gt;
&lt;br /&gt;
====Formatting====&lt;br /&gt;
&lt;br /&gt;
Formatting text to bold, italic, bulleted or numbered lists, tables etc. is most easily done in the Visual Editor. &lt;br /&gt;
&lt;br /&gt;
If you prefer to use the Source Editor, you can format your text by using wiki markup. This consists of normal characters like asterisks, apostrophes or equal signs which have a special function in the wiki, sometimes depending on their position. For example, to format a word in italic, you include it in two pairs of apostrophes like &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;''this''&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
''==&amp;gt; For more details see [[mediawikiwiki:Help:Formatting|Help:Formatting]] and the [[wikipedia:Help:Cheatsheet|Wiki cheat sheet]]''.&lt;br /&gt;
&lt;br /&gt;
====Sections====&lt;br /&gt;
A page can and should be divided into sections, using the section heading syntax. For each page with more than three section headings, a table of contents (TOC) is automatically generated. &lt;br /&gt;
&lt;br /&gt;
Sections are created by creating their headings, as below.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
== Section ==&lt;br /&gt;
=== Subsection ===&lt;br /&gt;
==== Sub-subsection ====&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Please do not use only one equals sign on a side (&amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;= Heading =&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;). This would cause a section heading to be as large as the page's name (title). The maximum number of equals signs is six. Heading names of sections (including subsections) should be unique on a page. Using the same heading more than once on a page causes problems.&lt;br /&gt;
&lt;br /&gt;
Linking to a section within the same page is done with the &amp;lt;nowiki&amp;gt;[[#Section_name]]&amp;lt;/nowiki&amp;gt; syntax. Linking to a section of another page on the same wiki is done by adding the &amp;quot;#&amp;quot; between the page name and the section name: &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[Page_name#Section_name]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;.  &lt;br /&gt;
&lt;br /&gt;
Section headers can be links to other pages: &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[===This section also has it's own page that can be opened via this link===]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;. The recommended practice is to place an excerpt, a summary or an overview of the dedicated page in the section content of the page being linked from.&lt;br /&gt;
&lt;br /&gt;
NEW! Sections can be numbered where necessary. To activate section numbering on a page add this syntax to the page source code (in the source editor): &amp;lt;nowiki&amp;gt;[[#Section_name]]&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==== Categories ====&lt;br /&gt;
In the DE4A wiki we use categories to indicate the status of a page:&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|+Overview of DE4A wiki page categories&lt;br /&gt;
!Category&lt;br /&gt;
!Description&lt;br /&gt;
|-&lt;br /&gt;
|Wip&lt;br /&gt;
|Page labeled as work In progress, not yet ready for review.&lt;br /&gt;
|-&lt;br /&gt;
|Draft&lt;br /&gt;
|Page labelled as a draft, ready for review.&lt;br /&gt;
|-&lt;br /&gt;
|Released&lt;br /&gt;
|A reviewed and finished page.&lt;br /&gt;
|}&lt;br /&gt;
A category label can be added to a page by inserting &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[Category:wip]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; at the top of the page in the Source Editor. &lt;br /&gt;
&lt;br /&gt;
A category page can be created the same way as other wiki pages; just add &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;Category:&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; before the page title. To avoid extra work, try searching within the wiki before creating a new category. The list of all categories can be found in the #List of pages section of the [[Special:SpecialPages#Lists of pages|Special Pages]] page.&lt;br /&gt;
&lt;br /&gt;
== Uploading files ==&lt;br /&gt;
&lt;br /&gt;
=== Files ===&lt;br /&gt;
Files can be uploaded via the Sidebar menu (Tools &amp;gt; Upload File) or while using the Visual Editor (Insert function). Files can be max 2MB in size and permitted file types are png, gif, jpg, jpeg, webp. Other files can be referenced via external links. Appropriate attention should be paid at all times to copyright and confidentiality considerations. &lt;br /&gt;
&lt;br /&gt;
===Images===&lt;br /&gt;
&lt;br /&gt;
The DE4A wiki includes an extension that makes it possible to display clickable image maps. An image map is a list of coordinates in a specific image, which hyperlinks areas of the image to multiple destinations (in contrast to a normal image link, in which the entire area of the image links to a single destination). For example, an application collaboration diagram may have each component or service hyperlinked to further information about that component or service. The intention of an image map is to provide an easy way of linking various parts of an image without dividing the image into separate image files.&lt;br /&gt;
&lt;br /&gt;
== Special pages ==&lt;br /&gt;
Special pages are pages generated by the wiki software on demand for special purposes, usually related to project maintenance. They can be found in the Tools section of the Sidebar (located on the left side of every page). Useful DE4A wiki special pages include:&lt;br /&gt;
&lt;br /&gt;
* [[Special:AllPages|All pages]] &lt;br /&gt;
* [[Special:ListFiles|Files]]&lt;br /&gt;
* [[Special:WantedPages|Wanted pages (red links)]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[https://wiki.de4a.eu/images/6/69/DE4A_-_VC_SSI-based_interaction_pattern_-_User_Story.pdf Wireframe Mock-up]&lt;/div&gt;</summary>
		<author><name>Ictu mavi.cristache</name></author>
	</entry>
	<entry>
		<id>https://wiki.de4a.eu/index.php?title=Getting_started&amp;diff=3775</id>
		<title>Getting started</title>
		<link rel="alternate" type="text/html" href="https://wiki.de4a.eu/index.php?title=Getting_started&amp;diff=3775"/>
		<updated>2021-11-03T11:59:34Z</updated>

		<summary type="html">&lt;p&gt;Ictu mavi.cristache: /* Sections */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;__NUMBEREDHEADINGS__&lt;br /&gt;
&lt;br /&gt;
[[Category:wip]]&lt;br /&gt;
Welcome, new editor of the DE4A documentation wiki! &lt;br /&gt;
&lt;br /&gt;
Before you beging adding content, you can familiarise yourself in on this page with some basic wiki rules and functionalities. All the tips and instructions listed below are also applied on this page, so feel free to copy syntax from the page source as needed. &lt;br /&gt;
&lt;br /&gt;
''==&amp;gt; Additional help is available in the [[wikipedia:Help:Cheatsheet|Wiki cheat sheet]], the [[mediawikiwiki:Special:MyLanguage/Help:Contents|User's Guide]], and the [[mediawikiwiki:Special:MyLanguage/Manual:FAQ|MediaWiki FAQ]].''&lt;br /&gt;
&lt;br /&gt;
==Ground rules==&lt;br /&gt;
'''#1 Create from search.''' When you want to create a new page, start by searching the wiki for existing content. If the search yields no results, you will be offered the option to create a new page. If you do, make sure your search was capitalised in Title Case. Make sure to also search the list of [[Special:WantedPages|Wanted Pages]] to make use of existing links (where possible) and prevent unwittingly duplicating a page name. &lt;br /&gt;
&lt;br /&gt;
'''#2 Page names in Title Case.''' Page names are capitalised using Wikipedia rules. When in doubt, use this [https://titlecaseconverter.com|Title Case Converter] tool to find the correct capitalisation. Different letter cases produce different wiki pages. For example, &amp;quot;[[Reference Interaction Patterns]]&amp;quot; and &amp;quot;[[Interaction patterns|Reference Interaction patterns]]&amp;quot; will lead to two different pages (the former exists on the DE4A wiki, the latter does not and should not, as it does not follow the Title Case capitalisation rule). &lt;br /&gt;
&lt;br /&gt;
'''#3 Ask for help.''' Don't hesitate to contact the [https://wiki.de4a.eu/index.php/Special:ActiveUsers?username=&amp;amp;groups%5B%5D=interface-admin&amp;amp;wpFormIdentifier=specialactiveusers|DE4A WP2 Team] for advice and support when or before adding your content to the wiki. We're here to think along and help.&lt;br /&gt;
&lt;br /&gt;
== Creating and editing pages  ==&lt;br /&gt;
===Starting a new page===&lt;br /&gt;
You can create a new page from a search or from a red link. In both cases, please observe the Title Case capitalisation rule (#2) above for naming the page. '''Page names cannot be edited anymore once created!''' &lt;br /&gt;
&lt;br /&gt;
''==&amp;gt; For more details see [[mediawikiwiki:Help:Starting_a_new_page|Help:Starting a new page.]]'' &lt;br /&gt;
===Editing===&lt;br /&gt;
You can edit the contents of a page with the Visual Editor or the Source Editor. The Visual Editor provides a direct visual way to edit pages based on the &amp;quot;what you see is what you get&amp;quot; principle. It contains a handy page searching function when inserting links. Visual editing is chosen by clicking the &amp;lt;kbd&amp;gt;Edit&amp;lt;/kbd&amp;gt; tab at the top of a page (or on a section-edit link). The Source Editor can be used for additional functionality with such things as categories, hyperlinks, tables and columns, footnotes, inline citation, special characters and so on. You can access the Source Editor by clicking the &amp;lt;kbd&amp;gt;Edit source&amp;lt;/kbd&amp;gt; tab at the top of a page (or on a section-edit link).  &lt;br /&gt;
&lt;br /&gt;
''==&amp;gt; For more help with the editing interfaces see [[mediawikiwiki:Help:Editing_pages|Help:Editing_pages]] and the [[mediawikiwiki:Help:VisualEditor/User_guide|Visual Editor User Guide]].''  &lt;br /&gt;
&lt;br /&gt;
====Links====&lt;br /&gt;
The most relevant two types of hypertext links in this wiki are internal links to other pages in the same wiki (commonly called &amp;quot;wikilinks&amp;quot;) and external links to pages at other websites. &lt;br /&gt;
&lt;br /&gt;
To create a so-called internal link to a page on the same wiki (a &amp;quot;wikilink&amp;quot;), use double square brackets wiki markup, &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[like this]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;. When you preview or save your changes, you will see a link that can be followed to the target page. If the page exists the link is displayed in blue; if the page does not exist, the link appears red (so the &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[like this]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; link is actually rendered [[like this]]). Following such a &amp;quot;redlink&amp;quot; to a missing page (whether or not it is actually red) will enable you to create the page.&lt;br /&gt;
&lt;br /&gt;
To markup any arbitrary string of text (not necessarily a page title) as a link, use a &amp;quot;vertical bar&amp;quot; or &amp;quot;pipe&amp;quot; character, like this: &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[Main Page|our project]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; results in the link [[Main Page|our project]].&lt;br /&gt;
&lt;br /&gt;
The first letter of the link target is usually not case-sensitive, meaning links can be capitalized or not (so How to contribute and how to contribute are equivalent). However, the case of every ''subsequent'' letter must match the target page exactly (so How to contribute and How To Contribute are ''not'' equivalent). Spaces in the page title may be represented as underscores (so How to contribute and How_to_contribute are again equivalent), but using underscores in links will make them visible in the page text (but this can be prevented by using a &amp;quot;pipe&amp;quot;). Please refer to '''rule #2''' above when naming pages to prevent creating duplicates.  &lt;br /&gt;
&lt;br /&gt;
If the page title you are linking to is that of the page you are editing, the result is not a hyperlink at all but simply bold text (for example, on this page the markup &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[Getting started]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; gives the result [[Getting started]]). If you're trying to create a wikilink to the current page, you probably want to link to a specific ''section'' or to an ''anchor'' within the page. You do that by adding a &amp;quot;#&amp;quot; before the section name: &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[#Ground rules]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; will lead to the [[#Ground rules]] section.&lt;br /&gt;
&lt;br /&gt;
Please note that links open by default in the same browser tab.&lt;br /&gt;
&lt;br /&gt;
''==&amp;gt; For more details see [[mediawikiwiki:Help:Links|Help:Links]]''.&lt;br /&gt;
&lt;br /&gt;
====Formatting====&lt;br /&gt;
&lt;br /&gt;
Formatting text to bold, italic, bulleted or numbered lists, tables etc. is most easily done in the Visual Editor. &lt;br /&gt;
&lt;br /&gt;
If you prefer to use the Source Editor, you can format your text by using wiki markup. This consists of normal characters like asterisks, apostrophes or equal signs which have a special function in the wiki, sometimes depending on their position. For example, to format a word in italic, you include it in two pairs of apostrophes like &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;''this''&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
''==&amp;gt; For more details see [[mediawikiwiki:Help:Formatting|Help:Formatting]] and the [[wikipedia:Help:Cheatsheet|Wiki cheat sheet]]''.&lt;br /&gt;
&lt;br /&gt;
====Sections====&lt;br /&gt;
A page can and should be divided into sections, using the section heading syntax. For each page with more than three section headings, a table of contents (TOC) is automatically generated. &lt;br /&gt;
&lt;br /&gt;
Sections are created by creating their headings, as below.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
== Section ==&lt;br /&gt;
=== Subsection ===&lt;br /&gt;
==== Sub-subsection ====&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Please do not use only one equals sign on a side (&amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;= Heading =&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;). This would cause a section heading to be as large as the page's name (title). The maximum number of equals signs is six. Heading names of sections (including subsections) should be unique on a page. Using the same heading more than once on a page causes problems.&lt;br /&gt;
&lt;br /&gt;
Linking to a section within the same page is done with the &amp;lt;nowiki&amp;gt;[[#Section_name]]&amp;lt;/nowiki&amp;gt; syntax. Linking to a section of another page on the same wiki is done by adding the &amp;quot;#&amp;quot; between the page name and the section name: &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[Page_name#Section_name]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;.  &lt;br /&gt;
&lt;br /&gt;
Section headers can be links to other pages: &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[===This section also has it's own page that can be opened via this link===]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;. The recommended practice is to place an excerpt, a summary or an overview of the dedicated page in the section content of the page being linked from.&lt;br /&gt;
&lt;br /&gt;
NEW! Sections can be numbered where necessary. To activate section numbering on a page add this syntax to the page source code (in the source editor): &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt; __NUMBEREDHEADINGS__ &amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==== Categories ====&lt;br /&gt;
In the DE4A wiki we use categories to indicate the status of a page:&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|+Overview of DE4A wiki page categories&lt;br /&gt;
!Category&lt;br /&gt;
!Description&lt;br /&gt;
|-&lt;br /&gt;
|Wip&lt;br /&gt;
|Page labeled as work In progress, not yet ready for review.&lt;br /&gt;
|-&lt;br /&gt;
|Draft&lt;br /&gt;
|Page labelled as a draft, ready for review.&lt;br /&gt;
|-&lt;br /&gt;
|Released&lt;br /&gt;
|A reviewed and finished page.&lt;br /&gt;
|}&lt;br /&gt;
A category label can be added to a page by inserting &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[Category:wip]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; at the top of the page in the Source Editor. &lt;br /&gt;
&lt;br /&gt;
A category page can be created the same way as other wiki pages; just add &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;Category:&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; before the page title. To avoid extra work, try searching within the wiki before creating a new category. The list of all categories can be found in the #List of pages section of the [[Special:SpecialPages#Lists of pages|Special Pages]] page.&lt;br /&gt;
&lt;br /&gt;
== Uploading files ==&lt;br /&gt;
&lt;br /&gt;
=== Files ===&lt;br /&gt;
Files can be uploaded via the Sidebar menu (Tools &amp;gt; Upload File) or while using the Visual Editor (Insert function). Files can be max 2MB in size and permitted file types are png, gif, jpg, jpeg, webp. Other files can be referenced via external links. Appropriate attention should be paid at all times to copyright and confidentiality considerations. &lt;br /&gt;
&lt;br /&gt;
===Images===&lt;br /&gt;
&lt;br /&gt;
The DE4A wiki includes an extension that makes it possible to display clickable image maps. An image map is a list of coordinates in a specific image, which hyperlinks areas of the image to multiple destinations (in contrast to a normal image link, in which the entire area of the image links to a single destination). For example, an application collaboration diagram may have each component or service hyperlinked to further information about that component or service. The intention of an image map is to provide an easy way of linking various parts of an image without dividing the image into separate image files.&lt;br /&gt;
&lt;br /&gt;
== Special pages ==&lt;br /&gt;
Special pages are pages generated by the wiki software on demand for special purposes, usually related to project maintenance. They can be found in the Tools section of the Sidebar (located on the left side of every page). Useful DE4A wiki special pages include:&lt;br /&gt;
&lt;br /&gt;
* [[Special:AllPages|All pages]] &lt;br /&gt;
* [[Special:ListFiles|Files]]&lt;br /&gt;
* [[Special:WantedPages|Wanted pages (red links)]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[https://wiki.de4a.eu/images/6/69/DE4A_-_VC_SSI-based_interaction_pattern_-_User_Story.pdf Wireframe Mock-up]&lt;/div&gt;</summary>
		<author><name>Ictu mavi.cristache</name></author>
	</entry>
	<entry>
		<id>https://wiki.de4a.eu/index.php?title=Getting_started&amp;diff=3774</id>
		<title>Getting started</title>
		<link rel="alternate" type="text/html" href="https://wiki.de4a.eu/index.php?title=Getting_started&amp;diff=3774"/>
		<updated>2021-11-03T11:59:03Z</updated>

		<summary type="html">&lt;p&gt;Ictu mavi.cristache: /* Sections */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;__NUMBEREDHEADINGS__&lt;br /&gt;
&lt;br /&gt;
[[Category:wip]]&lt;br /&gt;
Welcome, new editor of the DE4A documentation wiki! &lt;br /&gt;
&lt;br /&gt;
Before you beging adding content, you can familiarise yourself in on this page with some basic wiki rules and functionalities. All the tips and instructions listed below are also applied on this page, so feel free to copy syntax from the page source as needed. &lt;br /&gt;
&lt;br /&gt;
''==&amp;gt; Additional help is available in the [[wikipedia:Help:Cheatsheet|Wiki cheat sheet]], the [[mediawikiwiki:Special:MyLanguage/Help:Contents|User's Guide]], and the [[mediawikiwiki:Special:MyLanguage/Manual:FAQ|MediaWiki FAQ]].''&lt;br /&gt;
&lt;br /&gt;
==Ground rules==&lt;br /&gt;
'''#1 Create from search.''' When you want to create a new page, start by searching the wiki for existing content. If the search yields no results, you will be offered the option to create a new page. If you do, make sure your search was capitalised in Title Case. Make sure to also search the list of [[Special:WantedPages|Wanted Pages]] to make use of existing links (where possible) and prevent unwittingly duplicating a page name. &lt;br /&gt;
&lt;br /&gt;
'''#2 Page names in Title Case.''' Page names are capitalised using Wikipedia rules. When in doubt, use this [https://titlecaseconverter.com|Title Case Converter] tool to find the correct capitalisation. Different letter cases produce different wiki pages. For example, &amp;quot;[[Reference Interaction Patterns]]&amp;quot; and &amp;quot;[[Interaction patterns|Reference Interaction patterns]]&amp;quot; will lead to two different pages (the former exists on the DE4A wiki, the latter does not and should not, as it does not follow the Title Case capitalisation rule). &lt;br /&gt;
&lt;br /&gt;
'''#3 Ask for help.''' Don't hesitate to contact the [https://wiki.de4a.eu/index.php/Special:ActiveUsers?username=&amp;amp;groups%5B%5D=interface-admin&amp;amp;wpFormIdentifier=specialactiveusers|DE4A WP2 Team] for advice and support when or before adding your content to the wiki. We're here to think along and help.&lt;br /&gt;
&lt;br /&gt;
== Creating and editing pages  ==&lt;br /&gt;
===Starting a new page===&lt;br /&gt;
You can create a new page from a search or from a red link. In both cases, please observe the Title Case capitalisation rule (#2) above for naming the page. '''Page names cannot be edited anymore once created!''' &lt;br /&gt;
&lt;br /&gt;
''==&amp;gt; For more details see [[mediawikiwiki:Help:Starting_a_new_page|Help:Starting a new page.]]'' &lt;br /&gt;
===Editing===&lt;br /&gt;
You can edit the contents of a page with the Visual Editor or the Source Editor. The Visual Editor provides a direct visual way to edit pages based on the &amp;quot;what you see is what you get&amp;quot; principle. It contains a handy page searching function when inserting links. Visual editing is chosen by clicking the &amp;lt;kbd&amp;gt;Edit&amp;lt;/kbd&amp;gt; tab at the top of a page (or on a section-edit link). The Source Editor can be used for additional functionality with such things as categories, hyperlinks, tables and columns, footnotes, inline citation, special characters and so on. You can access the Source Editor by clicking the &amp;lt;kbd&amp;gt;Edit source&amp;lt;/kbd&amp;gt; tab at the top of a page (or on a section-edit link).  &lt;br /&gt;
&lt;br /&gt;
''==&amp;gt; For more help with the editing interfaces see [[mediawikiwiki:Help:Editing_pages|Help:Editing_pages]] and the [[mediawikiwiki:Help:VisualEditor/User_guide|Visual Editor User Guide]].''  &lt;br /&gt;
&lt;br /&gt;
====Links====&lt;br /&gt;
The most relevant two types of hypertext links in this wiki are internal links to other pages in the same wiki (commonly called &amp;quot;wikilinks&amp;quot;) and external links to pages at other websites. &lt;br /&gt;
&lt;br /&gt;
To create a so-called internal link to a page on the same wiki (a &amp;quot;wikilink&amp;quot;), use double square brackets wiki markup, &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[like this]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;. When you preview or save your changes, you will see a link that can be followed to the target page. If the page exists the link is displayed in blue; if the page does not exist, the link appears red (so the &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[like this]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; link is actually rendered [[like this]]). Following such a &amp;quot;redlink&amp;quot; to a missing page (whether or not it is actually red) will enable you to create the page.&lt;br /&gt;
&lt;br /&gt;
To markup any arbitrary string of text (not necessarily a page title) as a link, use a &amp;quot;vertical bar&amp;quot; or &amp;quot;pipe&amp;quot; character, like this: &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[Main Page|our project]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; results in the link [[Main Page|our project]].&lt;br /&gt;
&lt;br /&gt;
The first letter of the link target is usually not case-sensitive, meaning links can be capitalized or not (so How to contribute and how to contribute are equivalent). However, the case of every ''subsequent'' letter must match the target page exactly (so How to contribute and How To Contribute are ''not'' equivalent). Spaces in the page title may be represented as underscores (so How to contribute and How_to_contribute are again equivalent), but using underscores in links will make them visible in the page text (but this can be prevented by using a &amp;quot;pipe&amp;quot;). Please refer to '''rule #2''' above when naming pages to prevent creating duplicates.  &lt;br /&gt;
&lt;br /&gt;
If the page title you are linking to is that of the page you are editing, the result is not a hyperlink at all but simply bold text (for example, on this page the markup &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[Getting started]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; gives the result [[Getting started]]). If you're trying to create a wikilink to the current page, you probably want to link to a specific ''section'' or to an ''anchor'' within the page. You do that by adding a &amp;quot;#&amp;quot; before the section name: &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[#Ground rules]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; will lead to the [[#Ground rules]] section.&lt;br /&gt;
&lt;br /&gt;
Please note that links open by default in the same browser tab.&lt;br /&gt;
&lt;br /&gt;
''==&amp;gt; For more details see [[mediawikiwiki:Help:Links|Help:Links]]''.&lt;br /&gt;
&lt;br /&gt;
====Formatting====&lt;br /&gt;
&lt;br /&gt;
Formatting text to bold, italic, bulleted or numbered lists, tables etc. is most easily done in the Visual Editor. &lt;br /&gt;
&lt;br /&gt;
If you prefer to use the Source Editor, you can format your text by using wiki markup. This consists of normal characters like asterisks, apostrophes or equal signs which have a special function in the wiki, sometimes depending on their position. For example, to format a word in italic, you include it in two pairs of apostrophes like &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;''this''&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
''==&amp;gt; For more details see [[mediawikiwiki:Help:Formatting|Help:Formatting]] and the [[wikipedia:Help:Cheatsheet|Wiki cheat sheet]]''.&lt;br /&gt;
&lt;br /&gt;
====Sections====&lt;br /&gt;
A page can and should be divided into sections, using the section heading syntax. For each page with more than three section headings, a table of contents (TOC) is automatically generated. &lt;br /&gt;
&lt;br /&gt;
Sections are created by creating their headings, as below.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
== Section ==&lt;br /&gt;
=== Subsection ===&lt;br /&gt;
==== Sub-subsection ====&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Please do not use only one equals sign on a side (&amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;= Heading =&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;). This would cause a section heading to be as large as the page's name (title). The maximum number of equals signs is six. Heading names of sections (including subsections) should be unique on a page. Using the same heading more than once on a page causes problems.&lt;br /&gt;
&lt;br /&gt;
Linking to a section within the same page is done with the &amp;lt;nowiki&amp;gt;[[#Section_name]]&amp;lt;/nowiki&amp;gt; syntax. Linking to a section of another page on the same wiki is done by adding the &amp;quot;#&amp;quot; between the page name and the section name: &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[Page_name#Section_name]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;.  &lt;br /&gt;
&lt;br /&gt;
Section headers can be links to other pages: &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[===This section also has it's own page that can be opened via this link===]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;. The recommended practice is to place an excerpt, a summary or an overview of the dedicated page in the section content of the page being linked from.&lt;br /&gt;
&lt;br /&gt;
NEW! Sections can be numbered where necessary. To activate section numbering on a page add this syntax to the page source code (in the source editor): &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;__NUMBEREDHEADINGS__&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==== Categories ====&lt;br /&gt;
In the DE4A wiki we use categories to indicate the status of a page:&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|+Overview of DE4A wiki page categories&lt;br /&gt;
!Category&lt;br /&gt;
!Description&lt;br /&gt;
|-&lt;br /&gt;
|Wip&lt;br /&gt;
|Page labeled as work In progress, not yet ready for review.&lt;br /&gt;
|-&lt;br /&gt;
|Draft&lt;br /&gt;
|Page labelled as a draft, ready for review.&lt;br /&gt;
|-&lt;br /&gt;
|Released&lt;br /&gt;
|A reviewed and finished page.&lt;br /&gt;
|}&lt;br /&gt;
A category label can be added to a page by inserting &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[Category:wip]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; at the top of the page in the Source Editor. &lt;br /&gt;
&lt;br /&gt;
A category page can be created the same way as other wiki pages; just add &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;Category:&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; before the page title. To avoid extra work, try searching within the wiki before creating a new category. The list of all categories can be found in the #List of pages section of the [[Special:SpecialPages#Lists of pages|Special Pages]] page.&lt;br /&gt;
&lt;br /&gt;
== Uploading files ==&lt;br /&gt;
&lt;br /&gt;
=== Files ===&lt;br /&gt;
Files can be uploaded via the Sidebar menu (Tools &amp;gt; Upload File) or while using the Visual Editor (Insert function). Files can be max 2MB in size and permitted file types are png, gif, jpg, jpeg, webp. Other files can be referenced via external links. Appropriate attention should be paid at all times to copyright and confidentiality considerations. &lt;br /&gt;
&lt;br /&gt;
===Images===&lt;br /&gt;
&lt;br /&gt;
The DE4A wiki includes an extension that makes it possible to display clickable image maps. An image map is a list of coordinates in a specific image, which hyperlinks areas of the image to multiple destinations (in contrast to a normal image link, in which the entire area of the image links to a single destination). For example, an application collaboration diagram may have each component or service hyperlinked to further information about that component or service. The intention of an image map is to provide an easy way of linking various parts of an image without dividing the image into separate image files.&lt;br /&gt;
&lt;br /&gt;
== Special pages ==&lt;br /&gt;
Special pages are pages generated by the wiki software on demand for special purposes, usually related to project maintenance. They can be found in the Tools section of the Sidebar (located on the left side of every page). Useful DE4A wiki special pages include:&lt;br /&gt;
&lt;br /&gt;
* [[Special:AllPages|All pages]] &lt;br /&gt;
* [[Special:ListFiles|Files]]&lt;br /&gt;
* [[Special:WantedPages|Wanted pages (red links)]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[https://wiki.de4a.eu/images/6/69/DE4A_-_VC_SSI-based_interaction_pattern_-_User_Story.pdf Wireframe Mock-up]&lt;/div&gt;</summary>
		<author><name>Ictu mavi.cristache</name></author>
	</entry>
	<entry>
		<id>https://wiki.de4a.eu/index.php?title=Getting_started&amp;diff=3773</id>
		<title>Getting started</title>
		<link rel="alternate" type="text/html" href="https://wiki.de4a.eu/index.php?title=Getting_started&amp;diff=3773"/>
		<updated>2021-11-03T11:57:57Z</updated>

		<summary type="html">&lt;p&gt;Ictu mavi.cristache: Added section numbering info&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;__NUMBEREDHEADINGS__&lt;br /&gt;
&lt;br /&gt;
[[Category:wip]]&lt;br /&gt;
Welcome, new editor of the DE4A documentation wiki! &lt;br /&gt;
&lt;br /&gt;
Before you beging adding content, you can familiarise yourself in on this page with some basic wiki rules and functionalities. All the tips and instructions listed below are also applied on this page, so feel free to copy syntax from the page source as needed. &lt;br /&gt;
&lt;br /&gt;
''==&amp;gt; Additional help is available in the [[wikipedia:Help:Cheatsheet|Wiki cheat sheet]], the [[mediawikiwiki:Special:MyLanguage/Help:Contents|User's Guide]], and the [[mediawikiwiki:Special:MyLanguage/Manual:FAQ|MediaWiki FAQ]].''&lt;br /&gt;
&lt;br /&gt;
==Ground rules==&lt;br /&gt;
'''#1 Create from search.''' When you want to create a new page, start by searching the wiki for existing content. If the search yields no results, you will be offered the option to create a new page. If you do, make sure your search was capitalised in Title Case. Make sure to also search the list of [[Special:WantedPages|Wanted Pages]] to make use of existing links (where possible) and prevent unwittingly duplicating a page name. &lt;br /&gt;
&lt;br /&gt;
'''#2 Page names in Title Case.''' Page names are capitalised using Wikipedia rules. When in doubt, use this [https://titlecaseconverter.com|Title Case Converter] tool to find the correct capitalisation. Different letter cases produce different wiki pages. For example, &amp;quot;[[Reference Interaction Patterns]]&amp;quot; and &amp;quot;[[Interaction patterns|Reference Interaction patterns]]&amp;quot; will lead to two different pages (the former exists on the DE4A wiki, the latter does not and should not, as it does not follow the Title Case capitalisation rule). &lt;br /&gt;
&lt;br /&gt;
'''#3 Ask for help.''' Don't hesitate to contact the [https://wiki.de4a.eu/index.php/Special:ActiveUsers?username=&amp;amp;groups%5B%5D=interface-admin&amp;amp;wpFormIdentifier=specialactiveusers|DE4A WP2 Team] for advice and support when or before adding your content to the wiki. We're here to think along and help.&lt;br /&gt;
&lt;br /&gt;
== Creating and editing pages  ==&lt;br /&gt;
===Starting a new page===&lt;br /&gt;
You can create a new page from a search or from a red link. In both cases, please observe the Title Case capitalisation rule (#2) above for naming the page. '''Page names cannot be edited anymore once created!''' &lt;br /&gt;
&lt;br /&gt;
''==&amp;gt; For more details see [[mediawikiwiki:Help:Starting_a_new_page|Help:Starting a new page.]]'' &lt;br /&gt;
===Editing===&lt;br /&gt;
You can edit the contents of a page with the Visual Editor or the Source Editor. The Visual Editor provides a direct visual way to edit pages based on the &amp;quot;what you see is what you get&amp;quot; principle. It contains a handy page searching function when inserting links. Visual editing is chosen by clicking the &amp;lt;kbd&amp;gt;Edit&amp;lt;/kbd&amp;gt; tab at the top of a page (or on a section-edit link). The Source Editor can be used for additional functionality with such things as categories, hyperlinks, tables and columns, footnotes, inline citation, special characters and so on. You can access the Source Editor by clicking the &amp;lt;kbd&amp;gt;Edit source&amp;lt;/kbd&amp;gt; tab at the top of a page (or on a section-edit link).  &lt;br /&gt;
&lt;br /&gt;
''==&amp;gt; For more help with the editing interfaces see [[mediawikiwiki:Help:Editing_pages|Help:Editing_pages]] and the [[mediawikiwiki:Help:VisualEditor/User_guide|Visual Editor User Guide]].''  &lt;br /&gt;
&lt;br /&gt;
====Links====&lt;br /&gt;
The most relevant two types of hypertext links in this wiki are internal links to other pages in the same wiki (commonly called &amp;quot;wikilinks&amp;quot;) and external links to pages at other websites. &lt;br /&gt;
&lt;br /&gt;
To create a so-called internal link to a page on the same wiki (a &amp;quot;wikilink&amp;quot;), use double square brackets wiki markup, &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[like this]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;. When you preview or save your changes, you will see a link that can be followed to the target page. If the page exists the link is displayed in blue; if the page does not exist, the link appears red (so the &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[like this]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; link is actually rendered [[like this]]). Following such a &amp;quot;redlink&amp;quot; to a missing page (whether or not it is actually red) will enable you to create the page.&lt;br /&gt;
&lt;br /&gt;
To markup any arbitrary string of text (not necessarily a page title) as a link, use a &amp;quot;vertical bar&amp;quot; or &amp;quot;pipe&amp;quot; character, like this: &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[Main Page|our project]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; results in the link [[Main Page|our project]].&lt;br /&gt;
&lt;br /&gt;
The first letter of the link target is usually not case-sensitive, meaning links can be capitalized or not (so How to contribute and how to contribute are equivalent). However, the case of every ''subsequent'' letter must match the target page exactly (so How to contribute and How To Contribute are ''not'' equivalent). Spaces in the page title may be represented as underscores (so How to contribute and How_to_contribute are again equivalent), but using underscores in links will make them visible in the page text (but this can be prevented by using a &amp;quot;pipe&amp;quot;). Please refer to '''rule #2''' above when naming pages to prevent creating duplicates.  &lt;br /&gt;
&lt;br /&gt;
If the page title you are linking to is that of the page you are editing, the result is not a hyperlink at all but simply bold text (for example, on this page the markup &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[Getting started]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; gives the result [[Getting started]]). If you're trying to create a wikilink to the current page, you probably want to link to a specific ''section'' or to an ''anchor'' within the page. You do that by adding a &amp;quot;#&amp;quot; before the section name: &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[#Ground rules]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; will lead to the [[#Ground rules]] section.&lt;br /&gt;
&lt;br /&gt;
Please note that links open by default in the same browser tab.&lt;br /&gt;
&lt;br /&gt;
''==&amp;gt; For more details see [[mediawikiwiki:Help:Links|Help:Links]]''.&lt;br /&gt;
&lt;br /&gt;
====Formatting====&lt;br /&gt;
&lt;br /&gt;
Formatting text to bold, italic, bulleted or numbered lists, tables etc. is most easily done in the Visual Editor. &lt;br /&gt;
&lt;br /&gt;
If you prefer to use the Source Editor, you can format your text by using wiki markup. This consists of normal characters like asterisks, apostrophes or equal signs which have a special function in the wiki, sometimes depending on their position. For example, to format a word in italic, you include it in two pairs of apostrophes like &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;''this''&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
''==&amp;gt; For more details see [[mediawikiwiki:Help:Formatting|Help:Formatting]] and the [[wikipedia:Help:Cheatsheet|Wiki cheat sheet]]''.&lt;br /&gt;
&lt;br /&gt;
====Sections====&lt;br /&gt;
A page can and should be divided into sections, using the section heading syntax. For each page with more than three section headings, a table of contents (TOC) is automatically generated. &lt;br /&gt;
&lt;br /&gt;
Sections are created by creating their headings, as below.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
== Section ==&lt;br /&gt;
=== Subsection ===&lt;br /&gt;
==== Sub-subsection ====&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Please do not use only one equals sign on a side (&amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;= Heading =&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;). This would cause a section heading to be as large as the page's name (title). The maximum number of equals signs is six. Heading names of sections (including subsections) should be unique on a page. Using the same heading more than once on a page causes problems.&lt;br /&gt;
&lt;br /&gt;
Linking to a section within the same page is done with the &amp;lt;nowiki&amp;gt;[[#Section_name]]&amp;lt;/nowiki&amp;gt; syntax. Linking to a section of another page on the same wiki is done by adding the &amp;quot;#&amp;quot; between the page name and the section name: &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[Page_name#Section_name]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;.  &lt;br /&gt;
&lt;br /&gt;
Section headers can be links to other pages: &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[===This section also has it's own page that can be opened via this link===]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;. The recommended practice is to place an excerpt, a summary or an overview of the dedicated page in the section content of the page being linked from.&lt;br /&gt;
&lt;br /&gt;
NEW! Sections can be numbered where necessary. To activate section numbering on a page add tag to the page source code (in the source editor): &amp;lt;nowiki&amp;gt;__NUMBEREDHEADINGS__&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==== Categories ====&lt;br /&gt;
In the DE4A wiki we use categories to indicate the status of a page:&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|+Overview of DE4A wiki page categories&lt;br /&gt;
!Category&lt;br /&gt;
!Description&lt;br /&gt;
|-&lt;br /&gt;
|Wip&lt;br /&gt;
|Page labeled as work In progress, not yet ready for review.&lt;br /&gt;
|-&lt;br /&gt;
|Draft&lt;br /&gt;
|Page labelled as a draft, ready for review.&lt;br /&gt;
|-&lt;br /&gt;
|Released&lt;br /&gt;
|A reviewed and finished page.&lt;br /&gt;
|}&lt;br /&gt;
A category label can be added to a page by inserting &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[Category:wip]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; at the top of the page in the Source Editor. &lt;br /&gt;
&lt;br /&gt;
A category page can be created the same way as other wiki pages; just add &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;Category:&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; before the page title. To avoid extra work, try searching within the wiki before creating a new category. The list of all categories can be found in the #List of pages section of the [[Special:SpecialPages#Lists of pages|Special Pages]] page.&lt;br /&gt;
&lt;br /&gt;
== Uploading files ==&lt;br /&gt;
&lt;br /&gt;
=== Files ===&lt;br /&gt;
Files can be uploaded via the Sidebar menu (Tools &amp;gt; Upload File) or while using the Visual Editor (Insert function). Files can be max 2MB in size and permitted file types are png, gif, jpg, jpeg, webp. Other files can be referenced via external links. Appropriate attention should be paid at all times to copyright and confidentiality considerations. &lt;br /&gt;
&lt;br /&gt;
===Images===&lt;br /&gt;
&lt;br /&gt;
The DE4A wiki includes an extension that makes it possible to display clickable image maps. An image map is a list of coordinates in a specific image, which hyperlinks areas of the image to multiple destinations (in contrast to a normal image link, in which the entire area of the image links to a single destination). For example, an application collaboration diagram may have each component or service hyperlinked to further information about that component or service. The intention of an image map is to provide an easy way of linking various parts of an image without dividing the image into separate image files.&lt;br /&gt;
&lt;br /&gt;
== Special pages ==&lt;br /&gt;
Special pages are pages generated by the wiki software on demand for special purposes, usually related to project maintenance. They can be found in the Tools section of the Sidebar (located on the left side of every page). Useful DE4A wiki special pages include:&lt;br /&gt;
&lt;br /&gt;
* [[Special:AllPages|All pages]] &lt;br /&gt;
* [[Special:ListFiles|Files]]&lt;br /&gt;
* [[Special:WantedPages|Wanted pages (red links)]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[https://wiki.de4a.eu/images/6/69/DE4A_-_VC_SSI-based_interaction_pattern_-_User_Story.pdf Wireframe Mock-up]&lt;/div&gt;</summary>
		<author><name>Ictu mavi.cristache</name></author>
	</entry>
	<entry>
		<id>https://wiki.de4a.eu/index.php?title=Getting_started&amp;diff=3772</id>
		<title>Getting started</title>
		<link rel="alternate" type="text/html" href="https://wiki.de4a.eu/index.php?title=Getting_started&amp;diff=3772"/>
		<updated>2021-11-03T11:55:36Z</updated>

		<summary type="html">&lt;p&gt;Ictu mavi.cristache: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;__NUMBEREDHEADINGS__&lt;br /&gt;
&lt;br /&gt;
[[Category:wip]]&lt;br /&gt;
Welcome, new editor of the DE4A documentation wiki! &lt;br /&gt;
&lt;br /&gt;
Before you beging adding content, you can familiarise yourself in on this page with some basic wiki rules and functionalities. All the tips and instructions listed below are also applied on this page, so feel free to copy syntax from the page source as needed. &lt;br /&gt;
&lt;br /&gt;
''==&amp;gt; Additional help is available in the [[wikipedia:Help:Cheatsheet|Wiki cheat sheet]], the [[mediawikiwiki:Special:MyLanguage/Help:Contents|User's Guide]], and the [[mediawikiwiki:Special:MyLanguage/Manual:FAQ|MediaWiki FAQ]].''&lt;br /&gt;
&lt;br /&gt;
==Ground rules==&lt;br /&gt;
'''#1 Create from search.''' When you want to create a new page, start by searching the wiki for existing content. If the search yields no results, you will be offered the option to create a new page. If you do, make sure your search was capitalised in Title Case. Make sure to also search the list of [[Special:WantedPages|Wanted Pages]] to make use of existing links (where possible) and prevent unwittingly duplicating a page name. &lt;br /&gt;
&lt;br /&gt;
'''#2 Page names in Title Case.''' Page names are capitalised using Wikipedia rules. When in doubt, use this [https://titlecaseconverter.com|Title Case Converter] tool to find the correct capitalisation. Different letter cases produce different wiki pages. For example, &amp;quot;[[Reference Interaction Patterns]]&amp;quot; and &amp;quot;[[Interaction patterns|Reference Interaction patterns]]&amp;quot; will lead to two different pages (the former exists on the DE4A wiki, the latter does not and should not, as it does not follow the Title Case capitalisation rule). &lt;br /&gt;
&lt;br /&gt;
'''#3 Ask for help.''' Don't hesitate to contact the [https://wiki.de4a.eu/index.php/Special:ActiveUsers?username=&amp;amp;groups%5B%5D=interface-admin&amp;amp;wpFormIdentifier=specialactiveusers|DE4A WP2 Team] for advice and support when or before adding your content to the wiki. We're here to think along and help.&lt;br /&gt;
&lt;br /&gt;
== Creating and editing pages  ==&lt;br /&gt;
===Starting a new page===&lt;br /&gt;
You can create a new page from a search or from a red link. In both cases, please observe the Title Case capitalisation rule (#2) above for naming the page. '''Page names cannot be edited anymore once created!''' &lt;br /&gt;
&lt;br /&gt;
''==&amp;gt; For more details see [[mediawikiwiki:Help:Starting_a_new_page|Help:Starting a new page.]]'' &lt;br /&gt;
===Editing===&lt;br /&gt;
You can edit the contents of a page with the Visual Editor or the Source Editor. The Visual Editor provides a direct visual way to edit pages based on the &amp;quot;what you see is what you get&amp;quot; principle. It contains a handy page searching function when inserting links. Visual editing is chosen by clicking the &amp;lt;kbd&amp;gt;Edit&amp;lt;/kbd&amp;gt; tab at the top of a page (or on a section-edit link). The Source Editor can be used for additional functionality with such things as categories, hyperlinks, tables and columns, footnotes, inline citation, special characters and so on. You can access the Source Editor by clicking the &amp;lt;kbd&amp;gt;Edit source&amp;lt;/kbd&amp;gt; tab at the top of a page (or on a section-edit link).  &lt;br /&gt;
&lt;br /&gt;
''==&amp;gt; For more help with the editing interfaces see [[mediawikiwiki:Help:Editing_pages|Help:Editing_pages]] and the [[mediawikiwiki:Help:VisualEditor/User_guide|Visual Editor User Guide]].''  &lt;br /&gt;
&lt;br /&gt;
====Links====&lt;br /&gt;
The most relevant two types of hypertext links in this wiki are internal links to other pages in the same wiki (commonly called &amp;quot;wikilinks&amp;quot;) and external links to pages at other websites. &lt;br /&gt;
&lt;br /&gt;
To create a so-called internal link to a page on the same wiki (a &amp;quot;wikilink&amp;quot;), use double square brackets wiki markup, &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[like this]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;. When you preview or save your changes, you will see a link that can be followed to the target page. If the page exists the link is displayed in blue; if the page does not exist, the link appears red (so the &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[like this]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; link is actually rendered [[like this]]). Following such a &amp;quot;redlink&amp;quot; to a missing page (whether or not it is actually red) will enable you to create the page.&lt;br /&gt;
&lt;br /&gt;
To markup any arbitrary string of text (not necessarily a page title) as a link, use a &amp;quot;vertical bar&amp;quot; or &amp;quot;pipe&amp;quot; character, like this: &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[Main Page|our project]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; results in the link [[Main Page|our project]].&lt;br /&gt;
&lt;br /&gt;
The first letter of the link target is usually not case-sensitive, meaning links can be capitalized or not (so How to contribute and how to contribute are equivalent). However, the case of every ''subsequent'' letter must match the target page exactly (so How to contribute and How To Contribute are ''not'' equivalent). Spaces in the page title may be represented as underscores (so How to contribute and How_to_contribute are again equivalent), but using underscores in links will make them visible in the page text (but this can be prevented by using a &amp;quot;pipe&amp;quot;). Please refer to '''rule #2''' above when naming pages to prevent creating duplicates.  &lt;br /&gt;
&lt;br /&gt;
If the page title you are linking to is that of the page you are editing, the result is not a hyperlink at all but simply bold text (for example, on this page the markup &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[Getting started]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; gives the result [[Getting started]]). If you're trying to create a wikilink to the current page, you probably want to link to a specific ''section'' or to an ''anchor'' within the page. You do that by adding a &amp;quot;#&amp;quot; before the section name: &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[#Ground rules]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; will lead to the [[#Ground rules]] section.&lt;br /&gt;
&lt;br /&gt;
Please note that links open by default in the same browser tab.&lt;br /&gt;
&lt;br /&gt;
''==&amp;gt; For more details see [[mediawikiwiki:Help:Links|Help:Links]]''.&lt;br /&gt;
&lt;br /&gt;
====Formatting====&lt;br /&gt;
&lt;br /&gt;
Formatting text to bold, italic, bulleted or numbered lists, tables etc. is most easily done in the Visual Editor. &lt;br /&gt;
&lt;br /&gt;
If you prefer to use the Source Editor, you can format your text by using wiki markup. This consists of normal characters like asterisks, apostrophes or equal signs which have a special function in the wiki, sometimes depending on their position. For example, to format a word in italic, you include it in two pairs of apostrophes like &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;''this''&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
''==&amp;gt; For more details see [[mediawikiwiki:Help:Formatting|Help:Formatting]] and the [[wikipedia:Help:Cheatsheet|Wiki cheat sheet]]''.&lt;br /&gt;
&lt;br /&gt;
====Sections====&lt;br /&gt;
A page can and should be divided into sections, using the section heading syntax. For each page with more than three section headings, a table of contents (TOC) is automatically generated. &lt;br /&gt;
&lt;br /&gt;
Sections are created by creating their headings, as below.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
== Section ==&lt;br /&gt;
=== Subsection ===&lt;br /&gt;
==== Sub-subsection ====&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Please do not use only one equals sign on a side (&amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;= Heading =&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;). This would cause a section heading to be as large as the page's name (title). The maximum number of equals signs is six. Heading names of sections (including subsections) should be unique on a page. Using the same heading more than once on a page causes problems.&lt;br /&gt;
&lt;br /&gt;
Linking to a section within the same page is done with the &amp;lt;nowiki&amp;gt;[[#Section_name]]&amp;lt;/nowiki&amp;gt; syntax. Linking to a section of another page on the same wiki is done by adding the &amp;quot;#&amp;quot; between the page name and the section name: &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[Page_name#Section_name]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;.  &lt;br /&gt;
&lt;br /&gt;
Section headers can be links to other pages: &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[===This section also has it's own page that can be opened via this link===]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt;. The recommended practice is to place an excerpt, a summary or an overview of the dedicated page in the section content of the page being linked from.&lt;br /&gt;
&lt;br /&gt;
==== Categories ====&lt;br /&gt;
In the DE4A wiki we use categories to indicate the status of a page:&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|+Overview of DE4A wiki page categories&lt;br /&gt;
!Category&lt;br /&gt;
!Description&lt;br /&gt;
|-&lt;br /&gt;
|Wip&lt;br /&gt;
|Page labeled as work In progress, not yet ready for review.&lt;br /&gt;
|-&lt;br /&gt;
|Draft&lt;br /&gt;
|Page labelled as a draft, ready for review.&lt;br /&gt;
|-&lt;br /&gt;
|Released&lt;br /&gt;
|A reviewed and finished page.&lt;br /&gt;
|}&lt;br /&gt;
A category label can be added to a page by inserting &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;[[Category:wip]]&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; at the top of the page in the Source Editor. &lt;br /&gt;
&lt;br /&gt;
A category page can be created the same way as other wiki pages; just add &amp;lt;code&amp;gt;&amp;lt;nowiki&amp;gt;Category:&amp;lt;/nowiki&amp;gt;&amp;lt;/code&amp;gt; before the page title. To avoid extra work, try searching within the wiki before creating a new category. The list of all categories can be found in the #List of pages section of the [[Special:SpecialPages#Lists of pages|Special Pages]] page.&lt;br /&gt;
&lt;br /&gt;
== Uploading files ==&lt;br /&gt;
&lt;br /&gt;
=== Files ===&lt;br /&gt;
Files can be uploaded via the Sidebar menu (Tools &amp;gt; Upload File) or while using the Visual Editor (Insert function). Files can be max 2MB in size and permitted file types are png, gif, jpg, jpeg, webp. Other files can be referenced via external links. Appropriate attention should be paid at all times to copyright and confidentiality considerations. &lt;br /&gt;
&lt;br /&gt;
===Images===&lt;br /&gt;
&lt;br /&gt;
The DE4A wiki includes an extension that makes it possible to display clickable image maps. An image map is a list of coordinates in a specific image, which hyperlinks areas of the image to multiple destinations (in contrast to a normal image link, in which the entire area of the image links to a single destination). For example, an application collaboration diagram may have each component or service hyperlinked to further information about that component or service. The intention of an image map is to provide an easy way of linking various parts of an image without dividing the image into separate image files.&lt;br /&gt;
&lt;br /&gt;
== Special pages ==&lt;br /&gt;
Special pages are pages generated by the wiki software on demand for special purposes, usually related to project maintenance. They can be found in the Tools section of the Sidebar (located on the left side of every page). Useful DE4A wiki special pages include:&lt;br /&gt;
&lt;br /&gt;
* [[Special:AllPages|All pages]] &lt;br /&gt;
* [[Special:ListFiles|Files]]&lt;br /&gt;
* [[Special:WantedPages|Wanted pages (red links)]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[https://wiki.de4a.eu/images/6/69/DE4A_-_VC_SSI-based_interaction_pattern_-_User_Story.pdf Wireframe Mock-up]&lt;/div&gt;</summary>
		<author><name>Ictu mavi.cristache</name></author>
	</entry>
	<entry>
		<id>https://wiki.de4a.eu/index.php?title=DBA_2nd_iteration_Solution_Architecture&amp;diff=3708</id>
		<title>DBA 2nd iteration Solution Architecture</title>
		<link rel="alternate" type="text/html" href="https://wiki.de4a.eu/index.php?title=DBA_2nd_iteration_Solution_Architecture&amp;diff=3708"/>
		<updated>2021-10-26T11:39:28Z</updated>

		<summary type="html">&lt;p&gt;Ictu mavi.cristache: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;__NUMBEREDHEADINGS__&lt;br /&gt;
&lt;br /&gt;
== DBA pilot iteration 2==&lt;br /&gt;
The 2nd pilot iteration for DBA consists of:&lt;br /&gt;
&lt;br /&gt;
#extending use of the intermediation pattern to allow for more fine grained powers validation: see chapter 2.&lt;br /&gt;
#the Subscription and notification pattern: see chapter 3.&lt;br /&gt;
#the Lookup pattern (the lookup of evidence, not individual attributes): see chapter 4.&lt;br /&gt;
&lt;br /&gt;
Chapter 5 specifies two additional requirements for the intermediation pattern to initiate subscriptions.&lt;br /&gt;
&lt;br /&gt;
==Solution architecture for DBA authentication and powers validation==&lt;br /&gt;
This section contains the eIDAS solution architecture for the DBA pilot. eIDAS will be used for piloting the intermediation pattern in DBA pilot iteration 1 and 2.&lt;br /&gt;
&lt;br /&gt;
In all DBA cases a natural person will represent a company in the cross-border eProcedure. In both iterations the powers of the representative will be validated. The granularity is different in both iterations though. In the first iteration only full powers will be validated. The pilot partners will use currently available eIDAS functionality for communicating this cross-borders. The second pilot iteration adds fine-grained powers validation to eIDAS. It allows for explicit expression of powers in a powers validation request and powers declaration. This requires extension of eIDAS with the SEMPER concepts and software.&lt;br /&gt;
&lt;br /&gt;
===General design decisions===&lt;br /&gt;
The DBA eIDAS architecture has been designed according to the following general design decisions (see [[DE4A D4.6 DBA Pilot Planning v1.0 final.pdf|DBA deliverable D4.6]]):&lt;br /&gt;
&lt;br /&gt;
#The DBA pilot will implement a pilot-eIDAS-network, meaning the Member States will implement dedicated pilot eIDAS nodes for cross-border authentication and powers validation that is isolated from the regular network of eIDAS nodes. As the project extends on the use of eIDAS with legal person attributes and powers validation, regular eIDAS nodes are not suitable for piloting. Furthermore, use of the dedicated eIDAS network allows for acceptance of non-notified eID for piloting only.&lt;br /&gt;
#The DBA pilot uses the eIDAS company identification attributes ('legal person attributes in eIDAS') to communicate the represented legal person to the DP. As most Member States do not provide these attributes currently, they need to be added for piloting.&lt;br /&gt;
#The DBA pilot will use eIDAS attribute profile 1.1 and/or CEF’s reference software for the eIDAS node version 2.4.&lt;br /&gt;
#The DBA pilot will use the SEMPER extension that is compatible with the eIDAS node 2.4 for fine-grained powers validation in the second pilot iteration.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Compared to current eIDAS practice, the use of eIDAS will be extended by the DBA pilot with:&lt;br /&gt;
#Requesting and sending legal person attributes (identifying the company that applies for the service). Although eIDAS has been able to send legal person attributes from the start, this functionality has been notified just twice (by IT and NL) and has not been used in production services.&lt;br /&gt;
#Validating powers of representation. This function is not part of the eIDAS-network currently.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Ad 1. Legal Person attributes &amp;amp; record matching at the DC&amp;lt;/u&amp;gt;&lt;br /&gt;
&lt;br /&gt;
*The pilot partners will send the mandatory eIDAS attributes for the legal person after successful authenticating and validating powers (LegalPersonIdentifier and LegalName).&lt;br /&gt;
*The Data evaluator in the DBA pilot needs record matching on the company to determine whether the company has been registered at the company portal prior to the pilot start (without LegalPersonIdentifier). The data evaluator will use the second mandatory eIDAS attribute (LegalName) for that purpose. If needed the Data evaluator interacts with the user to do additional checks in the matching process. Record matching at the data evaluator is an eProcedure portal (or data consumer) specific activity that does not need harmonisation across piloting partners.&lt;br /&gt;
*The data owner does not need to do record matching on the company as it can use the LegalPersonIdentifier to uniquely identify the company involved. This is a consequence of the pilot principle, that the authenticating proxy sends a LegalPersonIdentifier containing a company identifier that the business register itself uses in its company registration.&lt;br /&gt;
*Data evaluators and data owners do not need to do record matching on the ''natural person''. Therefore, no additional eIDAS attributes of the natural person are needed.&lt;br /&gt;
&lt;br /&gt;
For more information, please see [[DE4A D4.6 DBA Pilot Planning v1.0 final.pdf]]&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Ad 2. Powers validation&amp;lt;/u&amp;gt;&lt;br /&gt;
&lt;br /&gt;
*Pilot iteration 1 supports implicit full powers only. It uses the eIDAS network currently operational for sending the required information. The eIDAS infrastructure – from the start – supported exchange of natural person attributes as well as company identification attributes (‘legal person attributes’). The eIDAS regulation defined the minimum datasets for both the natural and the legal person. The eIDAS network lacks a possibility to specify the powers of representation though; attributes specifying the powers (‘the powers declaration’) have not been defined yet. Hence, in iteration 1 the pilot partners agreed on the following access policy rule: “In case of full powers, the eIDAS authentication will be successful and the authentication proxy sends the eIDAS legal person attributes as well. In case of insufficient powers, the authentication must fail at the eIDAS proxy.”. Only that way the data consumer knows whether the user has full powers or not.&lt;br /&gt;
* Pilot iteration 2 supports fine grained powers validation. By using the SEMPER extension on eIDAS, not only the natural and company identification attributes can be exchanged, an explicit powers declaration will be included as well. Using the extension, the data evaluator specifies the scope of the service the user needs powers for. After validating the powers, the authentication proxy constructs a powers declaration confirming or denying the person’s powers. This way, the extension allows for fine-grained powers validation.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Main design decisions regarding fine grained powers validation in iteration 2:&lt;br /&gt;
&lt;br /&gt;
#the DBA pilot allows for representation of legal persons by natural persons only.&lt;br /&gt;
#the DBA pilot does not allow for intermediary parties (e.g. employee of an accounting firm operating on behalf of the company).&lt;br /&gt;
#the DBA pilot will operate a list of harmonised services to express the extent of powers. Non-harmonised services will not be supported.&lt;br /&gt;
#the DBA pilot will use the SDG annex II procedures as starting point for the list of harmonised services.&lt;br /&gt;
#the DBA pilot will implement fine grained powers using the SEMPER extension to eIDAS or implement the SEMPER concepts in custom eIDAS software.&lt;br /&gt;
&lt;br /&gt;
For more information, please refer to [[DE4A D4.6 DBA Pilot Planning v1.0 final.pdf]]&lt;br /&gt;
&lt;br /&gt;
===Process realisation===&lt;br /&gt;
The table below presents the components that implement the application services for the DBA pilot.&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|+table: process realisation&lt;br /&gt;
|'''Process'''&lt;br /&gt;
|'''Application service'''&lt;br /&gt;
|'''Components'''&lt;br /&gt;
|-&lt;br /&gt;
| rowspan=&amp;quot;4&amp;quot; |Request authentication, including powers validation&lt;br /&gt;
| rowspan=&amp;quot;4&amp;quot; |Authentication  initiation&lt;br /&gt;
|eProcedure portal front-end&lt;br /&gt;
eProcedure portal back-end&lt;br /&gt;
|-&lt;br /&gt;
|Specific eIDAS connector&lt;br /&gt;
|-&lt;br /&gt;
|eIDAS connector&lt;br /&gt;
|-&lt;br /&gt;
|SEMPER extension&lt;br /&gt;
|-&lt;br /&gt;
|Authenticate user&lt;br /&gt;
|User authentication&lt;br /&gt;
|Identity Provider&lt;br /&gt;
|-&lt;br /&gt;
|Validate powers of representation&lt;br /&gt;
|User authentication&lt;br /&gt;
|Mandate Management System&lt;br /&gt;
|-&lt;br /&gt;
|Retrieve legal person attributes&lt;br /&gt;
|User authentication&lt;br /&gt;
|Legal Person attribute provider (may be same as Mandate Management System)&lt;br /&gt;
|-&lt;br /&gt;
| rowspan=&amp;quot;3&amp;quot; |Provide authentication details, including powers declaration&lt;br /&gt;
| rowspan=&amp;quot;3&amp;quot; |User authentication&lt;br /&gt;
|Specific eIDAS proxy&lt;br /&gt;
|-&lt;br /&gt;
|eIDAS proxy&lt;br /&gt;
|-&lt;br /&gt;
|SEMPER extension&lt;br /&gt;
|}&lt;br /&gt;
[[File:EIDAS_+_SEMPER.png|alt=|450x450px]]&lt;br /&gt;
 &lt;br /&gt;
===Component description===&lt;br /&gt;
The table below describes each of the components in this solution architecture. &lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|+table: component description&lt;br /&gt;
|'''Component'''&lt;br /&gt;
|'''Type'''&lt;br /&gt;
|'''Short description of its use'''&lt;br /&gt;
|'''Changes for 2nd iteration piloting'''&lt;br /&gt;
|-&lt;br /&gt;
|eProcedure portal Front-end&lt;br /&gt;
|DC specific&lt;br /&gt;
|The eProcedure portal Front-end handles all user interaction on the web. For piloting DBA, the eProcedure portal Front-end needs to add the eIDAS login option to the login-webpage. As the DBA Pilot will use a dedicated network of eIDAS nodes, the eIDAS login option should be separated  from the regular eIDAS login option (in case not already available on the  eProcedure portal).  &lt;br /&gt;
|None. &lt;br /&gt;
|-&lt;br /&gt;
|eProcedure portal Back-end&lt;br /&gt;
|&lt;br /&gt;
|The eProcedure portal Back-end connects to the national eIDAS node via the specific eIDAS connector. The DBA login option should invoke the dedicated eIDAS connector instead of the regular one (a different URL).&lt;br /&gt;
Furthermore, the eProcedure portal Back-end should evaluate the authentication result received from the eIDAS connector. &lt;br /&gt;
|In iteration 1 the eProcedure portal should request:&lt;br /&gt;
*authentication at ''LoA substantial''&lt;br /&gt;
*the natural person attributes (at least the mandatory ones) '''''- to be discussed. This does not work with node 2.5/profile 1.2 implemented by AT (and SE?).'''''&lt;br /&gt;
* the legal person attributes (at least the mandatory ones)&lt;br /&gt;
&lt;br /&gt;
In iteration 1 the eProcedure portal should apply the following rules for granting access after authentication:&lt;br /&gt;
&lt;br /&gt;
*deny the user access in case  of an “authentication failed”-reply.&lt;br /&gt;
*grant the user access in case  of an “authentication successful”-reply.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In iteration 2 the eProcedure portal should request:&lt;br /&gt;
&lt;br /&gt;
*authentication at ''LoA substantial''&lt;br /&gt;
*the legal person attributes only (at least the mandatory ones)&lt;br /&gt;
*request a powers validation on the applicable harmonised service&lt;br /&gt;
&lt;br /&gt;
In iteration 2 the eProcedure portal should apply the following rules for granting access after authentication:&lt;br /&gt;
&lt;br /&gt;
*deny the user access in case of an “authentication failed” or &amp;quot;powers not sufficient&amp;quot;&lt;br /&gt;
*grant the user access in case of an “authentication successful” and &amp;quot;powers sufficient&amp;quot;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Please note: we need to discuss the requesting of eIDAS MDS attributes taking eIDAS profile 1.2 (section 2.8) into account (request from AT).'''&lt;br /&gt;
|-&lt;br /&gt;
|Specific eIDAS connector&lt;br /&gt;
|Member State Specific&lt;br /&gt;
|The Member State specific component that translates national eID protocol into eIDAS (light) protocol for requesting authentication and powers validation.&lt;br /&gt;
Member States usually implement one or more components to ‘bridge’ eIDAS to the national eID infrastructure. As from CEF eIDAS reference software 2.0, Member States use the eIDAS Light protocol for this.  &lt;br /&gt;
| To enable fine grained powers validation in iteration 2, the specific eIDAS connector needs to be extended for requesting powers validation alongside authentication.&lt;br /&gt;
|-&lt;br /&gt;
|(pilot) eIDAS connector&lt;br /&gt;
|Common component (MS deployment)&lt;br /&gt;
|The component Member States implement to connect to the eIDAS network as a relying party. The connector accepts authentication requests from the data evaluators of the Member State and forwards the requests to the Member States that needs to authenticate the user. After authentication, the eIDAS connector receives the authentication results and sends them to the requesting data evaluator.&lt;br /&gt;
The eIDAS connector can be implemented using CEF’s reference software or a custom implementation compliant to the eIDAS interoperability specifications. The CEF reference software implements  – besides the eIDAS SAML profile – also the JSON/REST eIDAS Light protocol to connect to national infrastructure.&lt;br /&gt;
|No changes in 2nd pilot iteration.&lt;br /&gt;
|-&lt;br /&gt;
|SEMPER extension&lt;br /&gt;
|Common component (MS deployment)&lt;br /&gt;
|Component for extending the eIDAS connector and the eIDAS proxy to allow for explicit powers validation requests and powers declarations.&lt;br /&gt;
|Needs to be deployed by Member States for communicating fine grained powers in iteration 2. &lt;br /&gt;
This component has been developed by the SEMPER project and needs to be deployed on the eIDAS node of each of the Member States.&lt;br /&gt;
&lt;br /&gt;
As an alternative Member States May develop a custom implementation of the SEMPER software that complies with the SEMPER SAML interface specifications. &lt;br /&gt;
|-&lt;br /&gt;
|(pilot) eIDAS proxy&lt;br /&gt;
|Common component (MS deployment)&lt;br /&gt;
|The component Member States implement to allow authentication with their (notified) eID for services provided in other Member States. The eIDAS proxy receives authentication requests from relying Member States, coordinates authentication, retrieval of legal person attributes and powers validation. The eIDAS proxy then sends the result to the requesting eIDAS connector.&lt;br /&gt;
Just like the eIDAS connector, the eIDAS proxy can be implemented using CEF’s reference software or a custom implementation compliant to the eIDAS interoperability specifications. The CEF reference software implements – besides the eIDAS SAML profile – also the JSON/REST eIDAS Light protocol to connect to national infrastructure.&lt;br /&gt;
|No changes in 2nd pilot iteration.&lt;br /&gt;
|-&lt;br /&gt;
|Specific eIDAS proxy&lt;br /&gt;
|Member State Specific&lt;br /&gt;
|The Member State specific component that translates national eID protocol into eIDAS (light) protocol for performing authentication and powers validation. Member States usually implement one or more components to ‘bridge’ eIDAS to the national eID infrastructure. As from CEF eIDAS reference software 2.0, Member States use the eIDAS Light protocol for this. Furthermore, the eIDAS proxy coordinates the login process at the DP Member State by triggering the IdP, Legal Person AP and MMS.&lt;br /&gt;
|In the second pilot iteration the Specific eIDAS proxy needs to be adapted to translate the powers validation request (the scope of powers to be precise) to national powers taxonomy, send a powers validation request to the Mandate Management System in national protocol, receive and interpret the response from the Mandate Management System and translate it back to cross-border taxonomy.&lt;br /&gt;
|-&lt;br /&gt;
|Identity Provider&lt;br /&gt;
|Member State Specific&lt;br /&gt;
|The Identity Provider handles authentication of the natural person. The IdP may be notified under eIDAS, but does not need to be notified to be used in the DBA pilot.&lt;br /&gt;
|No changes in 2nd pilot iteration.&lt;br /&gt;
|-&lt;br /&gt;
|Legal Person AP&lt;br /&gt;
|Member State Specific&lt;br /&gt;
|Member States need to provide the identifying (mandatory) attributes of the legal person (eIDASLegalPersonID and eIDASLegalName) to the specific eIDAS proxy. Member States could provide optional attributes of the legal person. The Legal Person attributes may be integrated in the national eID scheme. For example, in eRecognition (NL) the mandate management system also provides the legal person attributes. Mandate Management System and Legal Person AP are one and the same component then.&lt;br /&gt;
|No changes in 2nd pilot iteration.&lt;br /&gt;
|-&lt;br /&gt;
|Mandate Management System&lt;br /&gt;
|Member State Specific&lt;br /&gt;
|Member State specific solutions for registration and validation of powers.&lt;br /&gt;
 &lt;br /&gt;
| In the DBA first pilot iteration, this source must be used to verify full powers. The declaration of powers that results from validating full powers is implicit: in case the authentication is successful, the user will have full powers to represent the company. &lt;br /&gt;
In the second pilot iteration, when using SEMPER, the powers declaration is explicit: the powers declaration relates to the requested powers declaration and can be a powers declaration for a specific eService as well as a (explicit) powers declaration for full powers. Optionally (depending on national implementation) the harmonised services need to be included in the MMS.&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
===Functional requirements===&lt;br /&gt;
&lt;br /&gt;
The table below presents the requirements that the data evaluator and the authentication connector and proxy must implement. &lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|'''Role'''&lt;br /&gt;
|'''Component'''&lt;br /&gt;
|'''Requirement'''&lt;br /&gt;
|&lt;br /&gt;
'''Use in pilot iteration 1'''&lt;br /&gt;
|'''Use in pilot iteration 2'''&lt;br /&gt;
|-&lt;br /&gt;
| rowspan=&amp;quot;6&amp;quot; |Data evaluator&lt;br /&gt;
| rowspan=&amp;quot;6&amp;quot; |eProcedure portal&lt;br /&gt;
|The eProcedure portal adds an eIDAS login option for piloting.&lt;br /&gt;
|x&lt;br /&gt;
|x&lt;br /&gt;
|-&lt;br /&gt;
|The eProcedure portal connects to a ''dedicated'' eIDAS pilot node.&lt;br /&gt;
|x&lt;br /&gt;
|x&lt;br /&gt;
|-&lt;br /&gt;
|The eProcedure portal requests eIDAS legal person attributes (mandatory ones)&lt;br /&gt;
|x&lt;br /&gt;
|x&lt;br /&gt;
|-&lt;br /&gt;
|The eProcedure portal grants the user access on behalf of the company in case of an “authentication successful” response.&lt;br /&gt;
|x&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|The eProcedure portal additionally constructs a fine-grained powers validation request.&lt;br /&gt;
|&lt;br /&gt;
|x&lt;br /&gt;
|-&lt;br /&gt;
|The eProcedure portal validates the Powers declaration received.&lt;br /&gt;
|&lt;br /&gt;
|x&lt;br /&gt;
|-&lt;br /&gt;
| rowspan=&amp;quot;3&amp;quot; |Authentication connector&lt;br /&gt;
|SEMPER extension&lt;br /&gt;
|MS implements SEMPER extension to the eIDAS connector.&lt;br /&gt;
|&lt;br /&gt;
|x&lt;br /&gt;
|-&lt;br /&gt;
|Specific eIDAS connector&lt;br /&gt;
|MS adapts the &amp;quot;specific eIDAS connector&amp;quot; to support powers validation requests and powers declarations&lt;br /&gt;
|&lt;br /&gt;
|x&lt;br /&gt;
|-&lt;br /&gt;
|eIDAS connector&lt;br /&gt;
|MS implements eIDAS connector 2.4. In case of a custom implementation (like Sweden) an attribute profile 1.1-compliant version of the connector will be used for piloting.&lt;br /&gt;
|x&lt;br /&gt;
|x&lt;br /&gt;
|-&lt;br /&gt;
| rowspan=&amp;quot;8&amp;quot; |Authentication proxy&lt;br /&gt;
|SEMPER extension&lt;br /&gt;
|MS implements SEMPER extension to the eIDAS proxy.&lt;br /&gt;
|&lt;br /&gt;
|x&lt;br /&gt;
|-&lt;br /&gt;
|Specific eIDAS proxy&lt;br /&gt;
|MS adapts the &amp;quot;specific eIDAS proxy&amp;quot; to support powers validation requests and powers declarations&lt;br /&gt;
|&lt;br /&gt;
|x&lt;br /&gt;
|-&lt;br /&gt;
| rowspan=&amp;quot;6&amp;quot; |eIDAS proxy&lt;br /&gt;
|MS implements CEF eIDAS proxy 2.4. &lt;br /&gt;
&lt;br /&gt;
In case of a custom implementation (like Sweden) an attribute profile 1.1-compliant  version of the connector will be used for piloting.&lt;br /&gt;
|x&lt;br /&gt;
|x&lt;br /&gt;
|-&lt;br /&gt;
|MS connects an IdP to the eIDAS proxy node for authenticating the natural person&lt;br /&gt;
|x&lt;br /&gt;
|x&lt;br /&gt;
|-&lt;br /&gt;
|MS connects attribute provider (AP) to eIDAS node for eIDAS legal person attributes (in case not integrated in the MMS)&lt;br /&gt;
|x&lt;br /&gt;
|x&lt;br /&gt;
|-&lt;br /&gt;
|MS connects mandate management system (MMS) to eIDAS node for validating powers. Note: AP and MMS could be the same data source.&lt;br /&gt;
|x&lt;br /&gt;
|x&lt;br /&gt;
|-&lt;br /&gt;
|MS validates (implicit) full powers&lt;br /&gt;
|x&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|MS adds fine-grained powers validation&lt;br /&gt;
|&lt;br /&gt;
|x&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
===Component Deployment===&lt;br /&gt;
The table below shows the required deployment of common components.&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|+&lt;br /&gt;
!Component&lt;br /&gt;
!Version&lt;br /&gt;
|-&lt;br /&gt;
|eIDAS connector&lt;br /&gt;
|CEF reference software version 2.4&lt;br /&gt;
or custom software implementing interoperability specs 1.1&lt;br /&gt;
|-&lt;br /&gt;
|eIDAS proxy&lt;br /&gt;
|CEF reference software version 2.4&lt;br /&gt;
&lt;br /&gt;
or custom software implementing interoperability specs 1.1&lt;br /&gt;
|-&lt;br /&gt;
|SEMPER extension&lt;br /&gt;
|The 2.4-compliant version of the SEMPER extension provided by Technical University Graz (SEMPER project)&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Open questions AT: &lt;br /&gt;
&lt;br /&gt;
*can we upgrade to eIDAS node 2.5? No compatible SEMPER extension available (check with TUG).&lt;br /&gt;
*can we adapt the way we request attributes for iteration 1? -&amp;gt; don't request the natural person attributes, use the natural person representative attributes for this (profile 1.2 style).&lt;br /&gt;
&lt;br /&gt;
===Configuration of authentication requests===&lt;br /&gt;
&amp;lt;u&amp;gt;Configuration for pilot iteration 1&amp;lt;/u&amp;gt;&lt;br /&gt;
*regular eIDAS request &amp;amp; response&lt;br /&gt;
**eIDAS attributes to request: natural person and legal person attributes (at least the mandatory ones)&lt;br /&gt;
**eIDAS attributes to respond with: natural person and legal person attributes (at least the mandatory ones) - including a copy of natural person attributes as ''representative'' is optional.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;u&amp;gt;Configuration for pilot iteration 2&amp;lt;/u&amp;gt;&lt;br /&gt;
&lt;br /&gt;
*regular eIDAS request &amp;amp; response&lt;br /&gt;
**eIDAS attributes to request: legal person attributes only (at least the mandatory ones)&lt;br /&gt;
**eIDAS attributes to respond with:legal person attributes (at least the mandatory ones) and ''representative'' natural person attributes (at least he mandatory ones) using the representative-prefix&lt;br /&gt;
&lt;br /&gt;
*powers validation request &amp;amp; powers declaration (response)&lt;br /&gt;
**request:&lt;br /&gt;
***scope of powers to validate&lt;br /&gt;
***type of representation allowed&lt;br /&gt;
***source of powers accepted&lt;br /&gt;
**response:&lt;br /&gt;
***validation result (successful or not)&lt;br /&gt;
***type of representation&lt;br /&gt;
***source of powers&lt;br /&gt;
&lt;br /&gt;
===Configuration of harmonised services===&lt;br /&gt;
Principles for configuration:&lt;br /&gt;
&lt;br /&gt;
*The DBA pilot will rely on a common library of services to express the extent of powers: the harmonised services. This way, each of the participating Member States understand the powers validation requests of other Member States. It's up to each of the Member States to translate the harmonised services into nationally defined services (authentication connector-side) / powers (authentication proxy-side).&lt;br /&gt;
* The DBA pilot will use the SDGR services as starting point. These services have been defined in European legislation (as procedures in annex II of the Regulation). Hence, they have been pre-defined and harmonised already across Europe. The DBA pilot defines the &amp;quot;SDGR&amp;quot; harmonised services catalogue for use in the SEMPER extension.&lt;br /&gt;
* The DBA pilot is not limited to SDGR services though, e.g. opening a branch cross-border is explicitly excluded from the SDGR, but is included in some of the pilot scenario's. For services 'beyond SDGR' the DBA pilot has defined the &amp;quot;SDGR+&amp;quot; harmonised services catalogue.&lt;br /&gt;
&lt;br /&gt;
Proposal for the harmonised services to express powers cross-border:&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|+&lt;br /&gt;
table: harmonised services for cross-border validation of powers&lt;br /&gt;
!Service catalogue&lt;br /&gt;
!Nr&lt;br /&gt;
!Harmonised service&lt;br /&gt;
|-&lt;br /&gt;
|SDGR&lt;br /&gt;
|1&lt;br /&gt;
|Notification of business activity, permission for exercising a business activity, changes of business activity and the termination of a business activity not involving insolvency or liquidation procedures&lt;br /&gt;
|-&lt;br /&gt;
|SDGR&lt;br /&gt;
|2&lt;br /&gt;
|Registration of an employer (a natural person) with compulsory pension and insurance schemes&lt;br /&gt;
|-&lt;br /&gt;
|SDGR&lt;br /&gt;
|3&lt;br /&gt;
|Registration of employees with compulsory pension and insurance schemes&lt;br /&gt;
|-&lt;br /&gt;
|SDGR&lt;br /&gt;
|4&lt;br /&gt;
|Submitting a corporate tax declaration&lt;br /&gt;
|-&lt;br /&gt;
|SDGR&lt;br /&gt;
|5&lt;br /&gt;
|Notification to the social security schemes of the end of contract with an employee, excluding procedures for the collective termination of employee contracts&lt;br /&gt;
|-&lt;br /&gt;
|SDGR&lt;br /&gt;
|6&lt;br /&gt;
|Payment of social contributions for employees&lt;br /&gt;
|-&lt;br /&gt;
|SDGR+&lt;br /&gt;
|1&lt;br /&gt;
|Starting of a company or opening a branch in another member state&lt;br /&gt;
|-&lt;br /&gt;
|SDGR+&lt;br /&gt;
|2&lt;br /&gt;
|Initial registration of a business activity with the business register&lt;br /&gt;
|}&lt;br /&gt;
*&lt;br /&gt;
&lt;br /&gt;
===Logical interfaces===&lt;br /&gt;
SAML interface specifications for regular authentication requests (pilot iteration 1) have been specified by CEF Digital: https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/eIDAS+eID+Profile&lt;br /&gt;
&lt;br /&gt;
SAML interfaces specification for SEMPER-extended authentication request and response (pilot iteration 2) have been specified by SEMPER: see chapter 6 from deliverable M3 Report on mandate attributes and solutions for cross-border mandate attributes - 1.0.&lt;br /&gt;
&lt;br /&gt;
[[File:2019-07-08 M3 Report on mandate attributes and solutions for cross-border mandate attributes - 1.0.pdf|border|left|2019-07-08 M3 Report on mandate attributes and solutions for cross-border mandate attributes - 1.0.pdf]]&lt;br /&gt;
&lt;br /&gt;
==Solution architecture for Subscription &amp;amp; Notification pattern==&lt;br /&gt;
This section specifies the solution for the Subscription &amp;amp; Notification pattern that will be piloted by the DBA pilot in the second iteration.  &lt;br /&gt;
&lt;br /&gt;
Within scope of the DBA pilot:&lt;br /&gt;
*Modify DO/DE Mocks for the S&amp;amp;N pattern: for testing the S&amp;amp;N pattern, new versions of the DO- and DE-mocks need to be developed by WP5.&lt;br /&gt;
*Common component for Cross-border subscriptions and notification.&lt;br /&gt;
*Event Notification, in line with PSA 2nd iteration: the PSA defines several options for implementing the S&amp;amp;N pattern. The option chosen provides a solution for notifying business events and triggering of the Lookup pattern in case (an updated version of) evidence is required by the DE.&lt;br /&gt;
&lt;br /&gt;
Outside scope of the DBA pilot:&lt;br /&gt;
*Inspecting the log files for examining an error in sending a subscription request or notification.&lt;br /&gt;
* Resend a subscription request in case of an error;&lt;br /&gt;
* Resending a notification in case of an error (notification front-end);&lt;br /&gt;
*Include the Evidence in the notification: in case the DE needs (an updated version of) the evidence, it will use the Lookup pattern.&lt;br /&gt;
*Authorisation of DE's subscribing and DO's notifying (the component &amp;quot;authorization controller&amp;quot;).&lt;br /&gt;
&lt;br /&gt;
To be analysed by WP3:      &lt;br /&gt;
&lt;br /&gt;
*DBA requests WP3 to examine the authorization controller for the S&amp;amp;N pattern. The DBA partners don't require the authorization controller for piloting, but are aware this component is needed in case of large scale use of the S&amp;amp;N pattern. For the S&amp;amp;N pattern, the authorization controller should:      &lt;br /&gt;
**Establish whether the DE is allowed to subscribe. This prevents unauthorised access to company data (in the form of notifications). This authorisation should be checked by the DT.&lt;br /&gt;
**Establish whether the DO is allowed to send a notification. This prevents unauthorised sending of (fake) notifications. This authorisation should be checked by the DR.&lt;br /&gt;
&lt;br /&gt;
Prerequisite from the DE4A-project is the use of eDelivery and AS4 for the exchange of messages in the S&amp;amp;N and Lookup patterns. This means that eDelivery will be used for:      &lt;br /&gt;
&lt;br /&gt;
#requesting a subscription (DE to DO)&lt;br /&gt;
# confirming a subscription (DO to DE)&lt;br /&gt;
# notifying a business event (DO to DE)&lt;br /&gt;
In the next sections the general design decisions, process realisations, component descriptions, requirements, component implementations and expected logical interfaces are described.&lt;br /&gt;
&lt;br /&gt;
===General Design Decisions===&lt;br /&gt;
The following design decisions have been applied to the solution for S&amp;amp;N:&lt;br /&gt;
*The DBA pilot uses one type of subscription message and one type of notification message that all DC’s and DP’s involved will use. The subscription message is for subscribing to cross-border events generated at the DP. The notification message is for notifying the DC of such events. If the DC desires the Evidence can be retrieved using the Lookup. This implies an update of the IEM (WP3).&lt;br /&gt;
*There will be just one data owner per Member State: the business register, where the subscription will be recorded and where the cross-border events are generated, i.e. the authentic source of company information. The pilot does not support multiple DO's / notifying authorities in one Member State.&lt;br /&gt;
*For a given subscription provider (data owner), just one subscription is allowed per combination of (a) data evaluator, (b) company and (c) event catalogue. In other words, the DE can not register multiple subscriptions for one single company and one event catalogue at a subscription provider. If this is required in the future (after piloting DBA), then this functionality needs to be added to the solution. &lt;br /&gt;
*Using a single subscription request, the DE will subscribe to updates for a single company in a single Member State. &lt;br /&gt;
**As soon as the DE wants to subscribe to updates of multiple companies at one DO, it needs to send multiple subscription request to that DO (one for each company it wants to subscribe to).&lt;br /&gt;
**As soon as the DE wants to subscribe to updates for one company in two Member States, it needs to request two separate subscriptions, one for each Member State. This use case is not applicable to the DBA pilot though.&lt;br /&gt;
*A notification concerns only one single event of one single company and will be addressed to only one Member State. &lt;br /&gt;
**In case DE's from different Member States have subscribed to business events of a specific company, the DP needs to notify each of the Member States individually.&lt;br /&gt;
**In case the DP needs to notify a DE of multiple events for a specific company, the DP needs to send multiple notifications (one for each event). &lt;br /&gt;
**In case the DP needs to notify a DE of one event impacting multiple companies, the DP needs to send multiple notifications (one for each company). &lt;br /&gt;
*Business event notification is considered an extension to the SDGR, hence explicit request and the preview functions won't be implemented.&lt;br /&gt;
*The S&amp;amp;N pattern has been designed without any user interaction.&lt;br /&gt;
*In contrary to the PSA for this pattern, the ending date &amp;amp; time for a subscription are voluntary, meaning that as long as the DE has not indicated the ending date &amp;amp; time, the subscription remains valid. Mandatory ending dates &amp;amp; time may lead to arbitrary ending dates set in the far future by the DE. Furthermore, there seems to be no legal basis for maximising the subscription period to - for example - 5 years. &lt;br /&gt;
*In this solution the DE is in charge of its subscriptions at any time. There is no requirement to allow the data owner to end subscriptions single handed (e.g. after the company ended its operation). &lt;br /&gt;
The OOP TS domain (WP5) provides the data requestor and data transferor with the components needed for exchange of cross-border subscription and notification messages.&lt;br /&gt;
&lt;br /&gt;
===Process realisation===&lt;br /&gt;
The solution for the S&amp;amp;N patterns includes required functionality of the OOP Technical System (common components) expressed as application components and interfaces in the diagram below. Some common components need to be implemented by the data requestor and data transferor, some components by the data evaluator and data owner and some are common components to be implemented by DE4A WP5. The image below depicts the solution for the Subscription &amp;amp; Notification pattern (S&amp;amp;N) with the familiar split in the different roles.&lt;br /&gt;
&lt;br /&gt;
[[File:OOP TS S&amp;amp;N.png|alt=OOP TS DBA Subscription &amp;amp; Notification|none|frame|OOP TS DBA Subscription &amp;amp; Notification]]&lt;br /&gt;
The table below presents the components that implement the application services for the DBA pilot. The process realisation is split in two (subscription and notification) as they are independently triggered. See [[Subscription and Notification Pattern|Subscription and Notification]] in the Project Start Architecture (PSA 2nd iteration) for more details.&lt;br /&gt;
&lt;br /&gt;
=====''Subscription''=====&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|'''Process'''&lt;br /&gt;
|'''Application Service'''&lt;br /&gt;
|'''Components'''&lt;br /&gt;
|-&lt;br /&gt;
|Initiate subscription (DC)&lt;br /&gt;
|Subscription Initiation&lt;br /&gt;
|&lt;br /&gt;
*eProcedure Back-office Backend&lt;br /&gt;
*Back-office to OOP TS interface&lt;br /&gt;
*DE4A connector&lt;br /&gt;
|-&lt;br /&gt;
|Change subscription (DC)&lt;br /&gt;
|Subscription Initiation&lt;br /&gt;
|&lt;br /&gt;
*eProcedure Back-office Backend&lt;br /&gt;
*Back-office to OOP TS interface&lt;br /&gt;
|-&lt;br /&gt;
|Lookup event provider routing information (DC)&lt;br /&gt;
|Inquire Routing Information&lt;br /&gt;
|&lt;br /&gt;
*IDK&lt;br /&gt;
*DNS &amp;amp; SML&lt;br /&gt;
*MS SMP&lt;br /&gt;
|-&lt;br /&gt;
|Send subscription request (DC)&lt;br /&gt;
|&lt;br /&gt;
*Message Encryption&lt;br /&gt;
*e-Signature Creation Service&lt;br /&gt;
*Data Exchange Service&lt;br /&gt;
&lt;br /&gt;
*&lt;br /&gt;
| eDelivery access point:&lt;br /&gt;
*Trust Service Provisioning&lt;br /&gt;
*Data Encryption/Decryption&lt;br /&gt;
*Data Exchange&lt;br /&gt;
|-&lt;br /&gt;
|Validate subscription request (DP)&lt;br /&gt;
|&lt;br /&gt;
*eSignature Validation Service&lt;br /&gt;
*Message Decryption&lt;br /&gt;
*Authority Check (out of scope)&lt;br /&gt;
|eDelivery access point:&lt;br /&gt;
*Trust Service Provisioning&lt;br /&gt;
*Data Encryption/Decryption&lt;br /&gt;
|-&lt;br /&gt;
|Evaluate subscription request (DP)&lt;br /&gt;
|Subscription Evaluation&lt;br /&gt;
|Subscription System&lt;br /&gt;
|-&lt;br /&gt;
|Exception: Prepare subscription error message (DP)&lt;br /&gt;
|Subscription Error Handling&lt;br /&gt;
|&lt;br /&gt;
*Subscription System&lt;br /&gt;
*IDK&lt;br /&gt;
*DNS &amp;amp; SML&lt;br /&gt;
*MS SMP&lt;br /&gt;
|-&lt;br /&gt;
|Exception: Send subscription error message (DP)&lt;br /&gt;
|&lt;br /&gt;
*Message Encryption&lt;br /&gt;
*e-Signature Creation Service&lt;br /&gt;
*Data Exchange Service&lt;br /&gt;
|eDelivery access point:&lt;br /&gt;
*Trust Service Provisioning&lt;br /&gt;
*Data Encryption/Decryption&lt;br /&gt;
*Data Exchange&lt;br /&gt;
|-&lt;br /&gt;
|Exception: Forward subscription error (DC)&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
*Back-office to OOP TS interface&lt;br /&gt;
*DE4A connector&lt;br /&gt;
|-&lt;br /&gt;
|Exception: Investigate reason for subscription error (DC)&lt;br /&gt;
|out of scope&lt;br /&gt;
|out of scope&lt;br /&gt;
|-&lt;br /&gt;
|Register subscription (DP)&lt;br /&gt;
|Subscription Creation and Update&lt;br /&gt;
|Subscription System&lt;br /&gt;
|-&lt;br /&gt;
|Confirm subscription (DP)&lt;br /&gt;
|Subscription Confirmation&lt;br /&gt;
|&lt;br /&gt;
*Subscription System&lt;br /&gt;
*DE4A connector&lt;br /&gt;
*IDK&lt;br /&gt;
*DNS &amp;amp; SML&lt;br /&gt;
*MS SMP&lt;br /&gt;
|-&lt;br /&gt;
|Send subscription confirmation (DP)&lt;br /&gt;
|&lt;br /&gt;
*Message Encryption&lt;br /&gt;
*e-Signature Creation Service&lt;br /&gt;
*Data Exchange Service&lt;br /&gt;
|eDelivery access point:&lt;br /&gt;
*Trust Service Provisioning&lt;br /&gt;
*Data Encryption/Decryption&lt;br /&gt;
*Data Exchange&lt;br /&gt;
|-&lt;br /&gt;
|Forward confirmation (DC)&lt;br /&gt;
|n/a&lt;br /&gt;
|&lt;br /&gt;
*Back-office to OOP TS interface&lt;br /&gt;
*DE4A connector&lt;br /&gt;
|-&lt;br /&gt;
|Log subscription information (DC)&lt;br /&gt;
|n/a&lt;br /&gt;
|eProcedure Back-office Backend&lt;br /&gt;
|}&lt;br /&gt;
=====''Notification''=====&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|'''Process'''&lt;br /&gt;
|'''Application Service'''&lt;br /&gt;
|'''Components'''&lt;br /&gt;
|-&lt;br /&gt;
|Identify cross-border event (DP)&lt;br /&gt;
|Cross-border Event Filter&lt;br /&gt;
|Cross-border Event Handler&lt;br /&gt;
|-&lt;br /&gt;
|Check subscriptions (DP)&lt;br /&gt;
|Subscription Lookup&lt;br /&gt;
|&lt;br /&gt;
*Cross-border Event Handler&lt;br /&gt;
*Subscription System&lt;br /&gt;
|-&lt;br /&gt;
|Prepare notification message and subscriber list (DP)&lt;br /&gt;
|Notification Message and Subscriber List Preparation&lt;br /&gt;
|&lt;br /&gt;
*Cross-border Event Handler&lt;br /&gt;
*DE4A connector&lt;br /&gt;
*Event handler to OOP TS interface&lt;br /&gt;
|-&lt;br /&gt;
|Exception: Resend past events (DP)&lt;br /&gt;
|out of scope&lt;br /&gt;
|out of scope&lt;br /&gt;
|-&lt;br /&gt;
|Resolve service metadata (DP)&lt;br /&gt;
|Inquire Routing Information&lt;br /&gt;
|&lt;br /&gt;
*IDK&lt;br /&gt;
*DNS &amp;amp; SML&lt;br /&gt;
*MS SMP&lt;br /&gt;
|-&lt;br /&gt;
|Exception: Resolve subscriber participant ID and inform National Contact Point (DP)&lt;br /&gt;
|out of scope&lt;br /&gt;
|out of scope&lt;br /&gt;
|-&lt;br /&gt;
|Send event notification (DP)&lt;br /&gt;
|&lt;br /&gt;
*Message Encryption&lt;br /&gt;
*e-Signature Creation Service&lt;br /&gt;
*Data Exchange Service&lt;br /&gt;
|eDelivery Access point:&lt;br /&gt;
*Trust Service Provisioning&lt;br /&gt;
*Data Encryption/Decryption&lt;br /&gt;
*Data Exchange&lt;br /&gt;
|-&lt;br /&gt;
|Validate event notification (DC)&lt;br /&gt;
|&lt;br /&gt;
*eSignature Validation Service&lt;br /&gt;
*Message Decryption&lt;br /&gt;
*Authority Check (out of scope)&lt;br /&gt;
|eDelivery Access point:&lt;br /&gt;
*Trust Service Provisioning&lt;br /&gt;
*Data Encryption/Decryption&lt;br /&gt;
*Data Exchange&lt;br /&gt;
|-&lt;br /&gt;
|Determine event response (DC)&lt;br /&gt;
|Event Evaluation&lt;br /&gt;
|eProcedure Back-office Backend&lt;br /&gt;
|-&lt;br /&gt;
|Request change of subscription (DC)&lt;br /&gt;
|&lt;br /&gt;
*Notification Mismatch Signal&lt;br /&gt;
*Update Notification Response Log&lt;br /&gt;
|eProcedure Back-office Backend&lt;br /&gt;
|-&lt;br /&gt;
|Dismiss event (DC)&lt;br /&gt;
|Update Notification Response Log&lt;br /&gt;
|eProcedure Back-office Backend&lt;br /&gt;
|-&lt;br /&gt;
|Trigger evidence lookup (DC)&lt;br /&gt;
|Update Notification Response Log&lt;br /&gt;
|eProcedure Back-office Backend&lt;br /&gt;
|-&lt;br /&gt;
|Notify Responsible Organization (DC)&lt;br /&gt;
|Update Notification Response Log&lt;br /&gt;
|eProcedure Back-office Backend&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
===Component description===&lt;br /&gt;
The following table lists the components indicated in the image above. Per component a short description of its use is given, by which role the component is used (i.e. DE, DR, DT, DO) and whether the component is MS specific or common functionality.  &lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|'''Component'''&lt;br /&gt;
|'''Short description of its use'''&lt;br /&gt;
|'''Role'''&lt;br /&gt;
|'''Genericness*'''&lt;br /&gt;
|'''Changes for 2nd iteration piloting'''&lt;br /&gt;
|-&lt;br /&gt;
|eProcedure Back-office Backend&lt;br /&gt;
|This component implements back-end functionality for executing the eProcedure. Examples in the context of S&amp;amp;N: &lt;br /&gt;
&lt;br /&gt;
*collecting relevant data for a subscription request&lt;br /&gt;
*keeping track of subscriptions of the DE&lt;br /&gt;
*processing subscription confirmations / errors&lt;br /&gt;
*determining an appropriate response to a notification (e.g. discard or Lookup updated evidence)&lt;br /&gt;
*updating logs&lt;br /&gt;
&lt;br /&gt;
|DE&lt;br /&gt;
|specific&lt;br /&gt;
|Requires new functionality for S&amp;amp;N pattern in each of the DE's. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''TBD''' is the required functionality generic enough to justify a common component that DE's can deploy? Each DE needs to keep track of its subscriptions and needs event interpretation functionality as well. To some extend, registering the subscriptions is a mirror of the subscription system of the DO. &lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
|Back-office to OOP TS&lt;br /&gt;
|Interface for connecting the DE's backoffice with the OOP TS for:&lt;br /&gt;
&lt;br /&gt;
*requesting (changes to) subscriptions&lt;br /&gt;
* receiving subscription confirmations / errors&lt;br /&gt;
*receiving notifications&lt;br /&gt;
Just like the portal to OOP TS interface (as described in the DBA first iteration solution architecture), Member States may choose to implement this interface in a generic way to bridge national OOP protocols to DE4A datamodel at one single place. Furthermore, Member States may choose to integrate both interfaces (portal to OOP TS and backoffice to OOP TS) in one single interface.&lt;br /&gt;
|DR&lt;br /&gt;
|specific&lt;br /&gt;
|Needs to be developed and implemented for the second iteration.&lt;br /&gt;
May be partial re-use of the portal to OOP TS interface. &lt;br /&gt;
|-&lt;br /&gt;
|DE4A Connector&lt;br /&gt;
|Taking care of eDelivery and IDK interfacing, shielding DR and DT from complexities and facilitating ease of implementation.&lt;br /&gt;
&lt;br /&gt;
Error handling and logging.&lt;br /&gt;
|DR, DT&lt;br /&gt;
|common&lt;br /&gt;
|Needs extension for S&amp;amp;N pattern to facilitate interaction on:&lt;br /&gt;
- subscriptions&lt;br /&gt;
&lt;br /&gt;
- notifications&lt;br /&gt;
|-&lt;br /&gt;
|IDK&lt;br /&gt;
|DE4A playground IDK: a web application for locating the service to reach out to.&lt;br /&gt;
|DR, DT&lt;br /&gt;
|common&lt;br /&gt;
|'''Change w.r.t. iteration 1?''' There is no evidence provider lookup, instead the endpoint where to send the subscription request to is needed. Also there is no evidence response.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
As the DBA pilot uses just one type subscription message with just one data provider per Member state (on NUTS0 level),  there is no need for dynamic discovery of the data provider. For the DBA pilot it is sufficient to use a simple configuration file with the required elements (member state and participant id) like in iteration 1.&lt;br /&gt;
&lt;br /&gt;
See logical interfaces section below&lt;br /&gt;
|-&lt;br /&gt;
|MS SMP&lt;br /&gt;
|For each subscription request/response, information on the receivers Access Point (URL) and its certificates are needed. Each member state hosts an SMP for this purpose (note: for testing one single centrally hosted DE4A SMP will be used). Before sending a request or response, the sending party queries the SMP of the receiver to get this info. &lt;br /&gt;
|DR, DT&lt;br /&gt;
|common&lt;br /&gt;
|None expected.&lt;br /&gt;
|-&lt;br /&gt;
|eDelivery Access Point&lt;br /&gt;
|This component – also referred to as eDelivery AS4 gateway – handles the secure transfer of the data, including  encryption and decryption as well as signing/sealing and validating  signatures/seals.&lt;br /&gt;
|DR, DT&lt;br /&gt;
|common&lt;br /&gt;
|Needs configuration for accepting subscription, notifications and lookup messages for the second iteration.&lt;br /&gt;
|-&lt;br /&gt;
|DNS &amp;amp; SML&lt;br /&gt;
|As there are multiple SMP’s, the sending party needs to know where to find the SMP of the receiver to get the actual  metadata. This location can be found in the centrally CEF-hosted DNS, that  will be queried by the access point of the sending member state. &lt;br /&gt;
&lt;br /&gt;
DNS entries will be created from the  registration of SMP’s: the SML, which is also centrally hosted by CEF. &lt;br /&gt;
| Central&lt;br /&gt;
|central&lt;br /&gt;
|None expected.&lt;br /&gt;
|-&lt;br /&gt;
|Cross-border Event Handler&lt;br /&gt;
|Application component handling the cross-border events. It filters all domestic events for relevant cross-border events and takes care of preparing a notification message and compiling a subscribers list to which the notification must be sent.&lt;br /&gt;
|DO&lt;br /&gt;
|common&lt;br /&gt;
|The Cross-border Event Handler could be part of the Connector or at least be a common component. All DPs need this functionality.&lt;br /&gt;
|-&lt;br /&gt;
|Subscription System&lt;br /&gt;
|Application component managing the entire life cycle of subscriptions, i.e. creation and maintaining subscriptions. It also offers functionality for validating subscriptions (does subject exist?, is the event supported?, is the subscription changing an existing subscription?), confirmation of a subscription and error handling.&lt;br /&gt;
|DO&lt;br /&gt;
|common&lt;br /&gt;
|To be developed&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''TBD''': is this generic enough to justify a common component that SO's may deploy if they like?&lt;br /&gt;
|}&lt;br /&gt;
&amp;lt;nowiki&amp;gt;*&amp;lt;/nowiki&amp;gt;genericness: specific: to be developed, deployed and hosted by MS; common: to be developed by WP5 and deployed and hosted by MS; central: to be developed, deployed and hosted by CEF&lt;br /&gt;
&lt;br /&gt;
===Functional requirements===&lt;br /&gt;
The table below presents the requirements that the components involved need to implement.&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|'''Component'''&lt;br /&gt;
|'''Nr'''&lt;br /&gt;
|'''DBA requirement'''&lt;br /&gt;
|'''Comment'''&lt;br /&gt;
|-&lt;br /&gt;
| rowspan=&amp;quot;9&amp;quot; |eProcedure Backoffice Backend&lt;br /&gt;
|1&lt;br /&gt;
|The DE should be able to subscribe to the combination of:&lt;br /&gt;
&lt;br /&gt;
#a company&lt;br /&gt;
#one or more business events (catalogue &amp;amp; type)&lt;br /&gt;
|For piloting it is sufficient to skip the specification of events to subscribe to. It will be all or none.&lt;br /&gt;
|-&lt;br /&gt;
|2&lt;br /&gt;
|The DE should monitor actual subscription at the DO by processing the subscription confirmation / error.&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|3&lt;br /&gt;
|The DE should have the option to set a defined time frame for receiving notifications to automatically end a subscription.&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|4&lt;br /&gt;
|The DE should be able to manage the “end date” of the subscription (prolong, shorten, …).&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|5&lt;br /&gt;
|The DE should be able to unsubscribe to all notifications for a company at once.&lt;br /&gt;
|See req 1. for piloting a &amp;quot;all or none&amp;quot; subscription is fine.&lt;br /&gt;
|-&lt;br /&gt;
|6&lt;br /&gt;
|The DE should at any time have an overview of all its subscriptions in order to manage them.&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|7&lt;br /&gt;
|The DE may process a notification instantly, but may also choose to process the notifications in batch, e.g. once a day or week.&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|8&lt;br /&gt;
|The DE should have a legal basis for processing business events.&lt;br /&gt;
|It’s up to the DE to manage this. The DE will be  accountable for its data processing.&lt;br /&gt;
|-&lt;br /&gt;
|9&lt;br /&gt;
|The DE should implement logic to decide when (by which events) to lookup evidence.&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
| rowspan=&amp;quot;3&amp;quot; |DE4A connector&lt;br /&gt;
|1&lt;br /&gt;
|The DR must confirm having received the notification (by the DR not the DE) to the DT.&lt;br /&gt;
|From that point on delivery of the notifications to the DE is the responsibility of the DR (and not the DT or DO).&lt;br /&gt;
|-&lt;br /&gt;
|2&lt;br /&gt;
|The DT needs to confirm having received the subscription request to the DR.&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|3&lt;br /&gt;
|Each message sent requires a confirmation from the receiving actor (acknowledgement). For technical error messages concerning a subscription, notification or lookup the existing WP5 list can be used. e.g. timed-out, component unavailable, XML error, etc.&lt;br /&gt;
|Errors need to be implemented for the messages required for both new patterns.&lt;br /&gt;
|-&lt;br /&gt;
|Back-office to OOP TS interface&lt;br /&gt;
|1&lt;br /&gt;
|The DR should provide a facility for delayed forwarding of notifications to the DE.&lt;br /&gt;
|The DR probably needs a queue for this. This queue should guarantee delivery of the notifications to the DE, even if the DE is not online at some point in time or some other error prevents sending the notification.&lt;br /&gt;
This functionality preferably is not part of the Connector which should remain stateless.&lt;br /&gt;
|-&lt;br /&gt;
| rowspan=&amp;quot;4&amp;quot; |Subscription system&lt;br /&gt;
|1&lt;br /&gt;
|The DO should send a confirmation of registering or changing the subscription to the DE.&lt;br /&gt;
|Including error code and handling.&lt;br /&gt;
|-&lt;br /&gt;
|2&lt;br /&gt;
|The DO should generate one of the following error messages in case of registration error:&lt;br /&gt;
1. subscription registration failed (e.g. actor not authorised to subscribe, company identifier not found)&lt;br /&gt;
&lt;br /&gt;
2. subscription change failed (e.g. subscription to change not found in subscription system).  &lt;br /&gt;
| For piloting these two business errors are sufficient. &lt;br /&gt;
Business list of errors might be extended in future releases (after piloting). &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
As a generic principle, the error message should convey little information in itself. Providing more information enables possible attackers in their attempts. &lt;br /&gt;
|-&lt;br /&gt;
|3&lt;br /&gt;
|The subscription system should register:&lt;br /&gt;
- data evaluator &lt;br /&gt;
&lt;br /&gt;
- company ID&lt;br /&gt;
&lt;br /&gt;
- business event&lt;br /&gt;
&lt;br /&gt;
- starting date &amp;amp; time&lt;br /&gt;
&lt;br /&gt;
- ending date &amp;amp; time&lt;br /&gt;
|Please note that, in piloting DBA, pilot partners will implement an 'all or nothing'-subscription. This way, a subscription for a specific company is for all business events at once or for none (no subscription then). Hence, the element &amp;quot;business event&amp;quot; will not be used to differentiate between business events that are and that aren't included in a subscription. &lt;br /&gt;
&lt;br /&gt;
The element &amp;quot;business event&amp;quot; may be included in the components data store for future use though (to be decided by WP5). &lt;br /&gt;
&lt;br /&gt;
Furthermore, the element may be generalised to &amp;quot;event&amp;quot; to cover future use of other types of events. &lt;br /&gt;
|-&lt;br /&gt;
|4&lt;br /&gt;
|The subscription system should allow for querying which data evaluators to notify in case of a business event.&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
| rowspan=&amp;quot;10&amp;quot; |Cross-border Event Handler&lt;br /&gt;
|1&lt;br /&gt;
|The cross-border event handler should:&lt;br /&gt;
&lt;br /&gt;
*translate national events to harmonised events (as defined by the event catalogue)&lt;br /&gt;
*filter national events for relevance (i.e. presence in event catalogue)&lt;br /&gt;
*query the subscription system for subscribers to a particular event&lt;br /&gt;
*construct notification message for each of the subscribers&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|2&lt;br /&gt;
|The DO should send notifications only for a business event occurring to a company for which the DE has subscribed  – for as long as the subscription is valid.&lt;br /&gt;
|For piloting is seems sufficient to notify one single Member State in case of an event at a time.&lt;br /&gt;
|-&lt;br /&gt;
|3&lt;br /&gt;
|The DO should include the company identifier in the notification to allow the DE to find the corresponding record in its registry.&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|4&lt;br /&gt;
|The DO should include additional company identifiers that the business event concern.&lt;br /&gt;
|E.g. The identifiers of the company / companies acquiring the company concerned.&lt;br /&gt;
|-&lt;br /&gt;
|5&lt;br /&gt;
|The DO should clearly state in the notification what business event has occurred.&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|6&lt;br /&gt;
|The DO should provide a timestamp of the business event separate from the timestamp of the notification.&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|7&lt;br /&gt;
|The DO may send notifications instantly, but may also send in batch, e.g. once a day or week.&lt;br /&gt;
|The DE does not confirm receiving the notification to the DO, the acknowledgement of the DE4A connector is sufficient.&lt;br /&gt;
|-&lt;br /&gt;
|8&lt;br /&gt;
|The DO should be able to send notifications independently of the availability of the DE.&lt;br /&gt;
|In order not to hinder the notification process of  the DO.&lt;br /&gt;
|-&lt;br /&gt;
|9&lt;br /&gt;
|The DO should not include any additional company data in the notification nor attach evidence of any type to the notification.&lt;br /&gt;
|Data minimisation.&lt;br /&gt;
&lt;br /&gt;
It will be up to the DE to process the notification. This might not need any additional data. &lt;br /&gt;
|-&lt;br /&gt;
|10&lt;br /&gt;
|The DO should implement one event for notifying &amp;quot;the company registration evidence has changed&amp;quot; (without specifying which business event has occurred - if any).&lt;br /&gt;
|To cover for data changes that might be relevant for the DE without being a direct consequence of the occurrence of a harmonised business event, e.g. e-mail address changed.&lt;br /&gt;
|-&lt;br /&gt;
| rowspan=&amp;quot;2&amp;quot; |Data service&lt;br /&gt;
|1&lt;br /&gt;
|The data service of the DO needs to be capable of detecting business events and triggering a notification.&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|2&lt;br /&gt;
|The data service of the DO needs to support the event type &amp;quot;Company registration evidence has changed&amp;quot;&lt;br /&gt;
|&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
The table below presents the requirements for the DE and DO mocks.&lt;br /&gt;
&lt;br /&gt;
* The DE mock should mock the eProcedure Back-office Backend. &lt;br /&gt;
* The DO mock should mock the cross-border event handler and subscription system.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|'''Component'''&lt;br /&gt;
|'''Nr'''&lt;br /&gt;
|'''DBA requirement'''&lt;br /&gt;
|'''Comment'''&lt;br /&gt;
|-&lt;br /&gt;
| rowspan=&amp;quot;4&amp;quot; |DE mock&lt;br /&gt;
|1&lt;br /&gt;
|Requesting a subscription:&lt;br /&gt;
&lt;br /&gt;
* user input: company identifier, starting date and time, ending date and time (optionally)&lt;br /&gt;
* user select: Data Owner&lt;br /&gt;
* construct subscription request&lt;br /&gt;
* show subscription request on web page&lt;br /&gt;
* XML output: send request to DE4A connector&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|2&lt;br /&gt;
|Show subscription confirmation on web page.&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|3&lt;br /&gt;
|Show subscription error on web page.&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|4&lt;br /&gt;
|Changing a registered subscription:&lt;br /&gt;
&lt;br /&gt;
* user input: company identifier, starting date and time, ending date and time (optionally)&lt;br /&gt;
* user select: Data Owner&lt;br /&gt;
* construct change request&lt;br /&gt;
* show change request on web page&lt;br /&gt;
* XML output: send request to DE4A connector&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
| rowspan=&amp;quot;2&amp;quot; |DO mock&lt;br /&gt;
|1&lt;br /&gt;
|Subscription system - process requests:&lt;br /&gt;
&lt;br /&gt;
* XML input: registration request / change request:&lt;br /&gt;
* register a subscription / change a registered subscription&lt;br /&gt;
* XML output: confirm registration / send registration error&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|2&lt;br /&gt;
|Event handler - Construct and send a notification:&lt;br /&gt;
&lt;br /&gt;
* user input: company identifier&lt;br /&gt;
* user select: harmonised event&lt;br /&gt;
* check subscriptions for this company &lt;br /&gt;
* show subscriptions on web page&lt;br /&gt;
* construct notification(s)&lt;br /&gt;
* show notifications XML on web page&lt;br /&gt;
* XML output: send notifications&lt;br /&gt;
|&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
===Component deployment===&lt;br /&gt;
&lt;br /&gt;
*DNS, SML will be reused from iteration 1.&lt;br /&gt;
* SMP, eDelivery Access Point will be reused from iteration 1.&lt;br /&gt;
* The IDK probably needs to change to allow for locating the subscription register.&lt;br /&gt;
* The DE4A Connector needs an update to support the S&amp;amp;N flows and messages.&lt;br /&gt;
*Various MS specific interfaces may be needed for (sub)system integration.&lt;br /&gt;
* Both DE and DO need to do bookkeeping of subscriptions.&lt;br /&gt;
* The DO needs cross-border event handling functionality&lt;br /&gt;
*The DE needs event interpretation functionality and triggers for follow-up actions, like Lookup of evidence.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Expectations for WP3:&lt;br /&gt;
&lt;br /&gt;
*design messages for subscription request, subscription confirmation, subscription error and notification.&lt;br /&gt;
* analysis and design authorisation controller (out of scope for piloting)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Expectation for WP5:&lt;br /&gt;
&lt;br /&gt;
*extend the DE4A connector for S&amp;amp;N&lt;br /&gt;
*extend (the configuration of) the integrated AS4 gateway for S&amp;amp;N&lt;br /&gt;
*adapt the IDK if required for S&amp;amp;N.&lt;br /&gt;
*design and develop the cross-border event handler&lt;br /&gt;
*advise on queuing solution for Back-office to OOP TS interface&lt;br /&gt;
*examine possibility for generic components for &amp;quot;subscription system&amp;quot; and S&amp;amp;N back-end functionality of &amp;quot;eProcedure back-office backend&amp;quot;&lt;br /&gt;
*develop the DE and Do mocks&lt;br /&gt;
&lt;br /&gt;
===Configuration of business events===&lt;br /&gt;
&lt;br /&gt;
Business events are defined by each of the Member States individually. Although there are commonalities, all event-lists of the Member States are different. To enable cross-border interpretation of business events harmonisation of events is needed. For piloting DBA, just a small selection of events will be piloted. The purpose of the DBA pilot is not to harmonise all events, but to validate the notification-mechanism. &lt;br /&gt;
&lt;br /&gt;
The DBA event list (catalogue &amp;quot;Business events&amp;quot;) builds upon the BRIS definitions. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
List of harmonised events in the Event catalogue &amp;quot;Business events&amp;quot;:&lt;br /&gt;
#Company ended its operations&lt;br /&gt;
#Company changed its legal form&lt;br /&gt;
#Company merger or takeover&lt;br /&gt;
#Company moved to another location&lt;br /&gt;
#Company administration changed&lt;br /&gt;
#Company registration evidence has changed&lt;br /&gt;
'''TO DO: validate within DBA pilot.''' &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
National-to-harmonised translation needs to be designed by each Member State. Example for NL below (concept). &lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|+&lt;br /&gt;
!nr&lt;br /&gt;
!harmonised event&lt;br /&gt;
!NL event equivalent&lt;br /&gt;
|-&lt;br /&gt;
|1&lt;br /&gt;
|Company ended its operations&lt;br /&gt;
|beëindigen rechtspersoon&lt;br /&gt;
opheffen onderneming&lt;br /&gt;
|-&lt;br /&gt;
|2&lt;br /&gt;
|Company changed its legal form&lt;br /&gt;
|omzetten rechtspersoon&lt;br /&gt;
|-&lt;br /&gt;
|3&lt;br /&gt;
|Company merger or takeover&lt;br /&gt;
|fuseren rechtspersoon&lt;br /&gt;
|-&lt;br /&gt;
|4&lt;br /&gt;
|Company moved to another location&lt;br /&gt;
|verhuizen vestiging&lt;br /&gt;
|-&lt;br /&gt;
|5&lt;br /&gt;
|Company administration changed&lt;br /&gt;
|toetreden bestuurder&lt;br /&gt;
&lt;br /&gt;
toetreden functionaris&lt;br /&gt;
&lt;br /&gt;
toetreden gemachtigde&lt;br /&gt;
&lt;br /&gt;
toetreden aansprakelijke bij samenwerkingsverband&lt;br /&gt;
&lt;br /&gt;
uittreden functionaris/bestuurder/gemachtigde/aansprakelijke bij samenwerkingsverband&lt;br /&gt;
|-&lt;br /&gt;
|6&lt;br /&gt;
|Company registration evidence has changed&lt;br /&gt;
|(not an event)&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===Logical interfaces===&lt;br /&gt;
The expected logical interfaces of the common components are expected to remain largely the same with an expansion for the S&amp;amp;N pattern. &lt;br /&gt;
&lt;br /&gt;
Note: We need to discuss with WP3/WP5 the implementation of the Data Service Lookup ABB. Right now this is covered by the IDK. However, for S&amp;amp;N there is no evidence lookup or exchange, so at least the name is off. Also the I/F with the Connector changes slightly. In the table below some differences are indicated.&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|'''Component'''&lt;br /&gt;
|'''Expected interface'''&lt;br /&gt;
|-&lt;br /&gt;
|IDK&lt;br /&gt;
|IN  (from DE4A connector to IDK):&lt;br /&gt;
&lt;br /&gt;
* Member state&lt;br /&gt;
&lt;br /&gt;
* Event catalogue (e.g. DBA = business event)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
OUT (from IDK to DE4A connector):&lt;br /&gt;
&lt;br /&gt;
* Participant ID&lt;br /&gt;
|-&lt;br /&gt;
|SMP&lt;br /&gt;
|IN  (from DE4A connector to SMP):&lt;br /&gt;
&lt;br /&gt;
* Participant ID&lt;br /&gt;
&lt;br /&gt;
OUT  (from SMP to DE4A connector):&lt;br /&gt;
&lt;br /&gt;
* Service URL&lt;br /&gt;
&lt;br /&gt;
* Certificate to use&lt;br /&gt;
|-&lt;br /&gt;
|DNS  &amp;amp; SML&lt;br /&gt;
|IN  (from DE4A connector to DNS):&lt;br /&gt;
&lt;br /&gt;
* Member state&lt;br /&gt;
&lt;br /&gt;
* Participant ID&lt;br /&gt;
&lt;br /&gt;
OUT  (from DNS to DE4A connector):&lt;br /&gt;
&lt;br /&gt;
* SMP location&lt;br /&gt;
|-&lt;br /&gt;
|eDelivery  AS4 gateway&lt;br /&gt;
|IN  (from DE4A connector to eDelivery Acess Point):&lt;br /&gt;
&lt;br /&gt;
* Subscription request/registration conformation/notification&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
OUT (from eDelivery Access Point to DE4A connector):&lt;br /&gt;
&lt;br /&gt;
* ACK&lt;br /&gt;
|-&lt;br /&gt;
|DE4A  Connector&lt;br /&gt;
|''Subscription''&lt;br /&gt;
Initiating or changing subscription&lt;br /&gt;
&lt;br /&gt;
IN  (from DE to DE4A connector):&lt;br /&gt;
&lt;br /&gt;
*request ID (correlation)&lt;br /&gt;
*subject identifier (company in question)&lt;br /&gt;
*data owner identifier (DO id = participant ID)&lt;br /&gt;
*subscriber identifier (DE id = participant ID)&lt;br /&gt;
*event catalogue (DBA fixed business events)&lt;br /&gt;
*(new) subscription start and end date&lt;br /&gt;
&lt;br /&gt;
OUT  (from DE4A connector to DE): &lt;br /&gt;
&lt;br /&gt;
*ACK  (from DT)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
''Subscription confirmation''&lt;br /&gt;
&lt;br /&gt;
IN (from DO to DE):&lt;br /&gt;
&lt;br /&gt;
*request ID&lt;br /&gt;
&lt;br /&gt;
*data owner identifier (DO id = participant ID)&lt;br /&gt;
*subscriber identifier (DE id = participant ID)&lt;br /&gt;
*status (success/fail)&lt;br /&gt;
&lt;br /&gt;
OUT (from DE to DO):&lt;br /&gt;
&lt;br /&gt;
*ACK&lt;br /&gt;
&lt;br /&gt;
''Notification''&lt;br /&gt;
&lt;br /&gt;
IN  (from DO to DE4A connector):&lt;br /&gt;
&lt;br /&gt;
*subscriber identifier (DE ID = participant ID)&lt;br /&gt;
*data owner identifier (DO id = participant ID)&lt;br /&gt;
*notification&lt;br /&gt;
&lt;br /&gt;
#subject identifier (company in question)&lt;br /&gt;
#event catalogue&lt;br /&gt;
#event&lt;br /&gt;
#timestamp event&lt;br /&gt;
&lt;br /&gt;
OUT (from DE4A connector to DR): &lt;br /&gt;
&lt;br /&gt;
*ACK (from DR)&lt;br /&gt;
|-&lt;br /&gt;
|Subscription system&lt;br /&gt;
|IN (from DE4A connector to subscription system) - for subscribing:&lt;br /&gt;
&lt;br /&gt;
* subscription request&lt;br /&gt;
&lt;br /&gt;
OUT:&lt;br /&gt;
&lt;br /&gt;
* subscription confirmation&lt;br /&gt;
&lt;br /&gt;
* subscription error&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
IN (from cross-border event handler) - for composing the list of notifications:&lt;br /&gt;
&lt;br /&gt;
* subject identifier (company in question)&lt;br /&gt;
&lt;br /&gt;
OUT:&lt;br /&gt;
&lt;br /&gt;
* list of subscribers (DE participant ID's).&lt;br /&gt;
|-&lt;br /&gt;
|Cross-border Event Handler&lt;br /&gt;
|IN&lt;br /&gt;
&lt;br /&gt;
* domestic event&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
OUT&lt;br /&gt;
&lt;br /&gt;
* array of notifications&lt;br /&gt;
&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
==Solution architecture for Lookup pattern==&lt;br /&gt;
This section specifies the solution for the Lookup pattern that will be piloted by the DBA pilot in the second iteration. Basically, the Lookup pattern will be implemented as the intermediation pattern, but without: user authentication, explicit request and preview. Instead of having the eProcedure portal managing the OOP TS flow in interaction with he user, it will be the eProcedure back-office that will initiate the lookup and process the evidence. &lt;br /&gt;
&lt;br /&gt;
The Lookup pattern will be used to quickly retrieve (updated) evidence needed to keep a local company data store up-to-date, to re-asses a service provided or for generic fraud prevention purposes. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Within scope of the DBA pilot:&lt;br /&gt;
*Evidence Lookup, the PSA defines several options for implementing the Lookup pattern. The option chosen is based on requesting (an updated version of) evidence.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Outside scope of the DBA pilot:&lt;br /&gt;
*Attribute Lookup: this solution architecture supports Evidence type lookup requesting the full evidence without user interaction. The option to request individual attributes / API-approach is not supported.&lt;br /&gt;
*Authorisation of DE's to retrieve the requested evidence (the component &amp;quot;authorisation controller&amp;quot;)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
To be analysed by WP3:&lt;br /&gt;
&lt;br /&gt;
*DBA requests WP3 to examine the authorization controller for the Lookup pattern. The DBA partners don't require the authorization controller for piloting, but are aware this component is needed in case of large scale use of the Lookup (and intermediation) pattern. For the Lookup pattern, the authorization controller should establish whether the DE is allowed to retrieve the requested evidence type. This prevents unauthorised access to company data. This authorisation should be checked by the DT.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Prerequisite from the DE4A-project is the use of eDelivery and AS4 for the exchange of messages in the Lookup pattern. This means that eDelivery in the Lookup pattern will be used for:&lt;br /&gt;
&lt;br /&gt;
#requesting evidence (DE to DO)&lt;br /&gt;
#sending the evidence (DO to DE)&lt;br /&gt;
&lt;br /&gt;
In the next sections the general design decisions, process realisations, component descriptions, requirements, component implementations and expected logical interfaces are described.&lt;br /&gt;
&lt;br /&gt;
===General Design Decisions===&lt;br /&gt;
The following design decisions have been applied to the solution for Lookup:&lt;br /&gt;
*Based on a received notification message (S&amp;amp;N pattern) the DC, if desired, retrieves the Evidence using the Lookup.&lt;br /&gt;
*The explicit request and the preview functions won't be implemented as Lookup is considered 'beyond SDGR'&lt;br /&gt;
*The Lookup has been designed without any user interaction.&lt;br /&gt;
The OOP TS domain (WP5) provides the data requestor and data transferor with the components needed for performing the lookup of an evidence.&lt;br /&gt;
&lt;br /&gt;
===Process realisation===&lt;br /&gt;
The solution for the Lookup pattern specifies required functionality of the OOP Technical System expressed as application components and interfaces in the diagram below. Some OOP TS components need to be implemented by the data requestor and data transferor, some components by the data evaluator and data owner and some are common components to be implemented by DE4A WP5. The image below depicts the solution for the Lookup Pattern (LKP) with the familiar split in the different roles.&lt;br /&gt;
&lt;br /&gt;
[[File:OOP TS LKP.png|alt=OOPT TS Lookup|none|frame|Components of the Lookup pattern]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
The table below presents the components that implement the application services for the DBA pilot. &lt;br /&gt;
&lt;br /&gt;
Please note that we assume the common components for the Lookup pattern can be re-used 1-on-1 of the intermediation pattern (same components, same functionality, same deployments). Only the initiation of the evidence request and the processing of the evidence response is different (not eProcedure portal but eProcedure backoffice). Hence, for the common components, just a referral has been included. For more information we refer to the solution architecture of the intermediation pattern. &lt;br /&gt;
&lt;br /&gt;
See [[Lookup Pattern]] for more details.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable sortable&amp;quot;&lt;br /&gt;
|'''Process'''&lt;br /&gt;
|'''Application Service'''&lt;br /&gt;
|'''Component'''&lt;br /&gt;
|-&lt;br /&gt;
|Determine required cross-border evidence (DC)&lt;br /&gt;
|Cross-border Evidence Matching&lt;br /&gt;
|eProcedure Backoffice Back-end: &lt;br /&gt;
&lt;br /&gt;
*Evidence Type Translator&lt;br /&gt;
&lt;br /&gt;
Back-office to OOP TS interface&lt;br /&gt;
|-&lt;br /&gt;
|''Lookup routing information (DC)''&lt;br /&gt;
|''See intermediation pattern''&lt;br /&gt;
|''See intermediation pattern''&lt;br /&gt;
|-&lt;br /&gt;
|''Request evidence (DC)''&lt;br /&gt;
|''See intermediation pattern''&lt;br /&gt;
|''See intermediation pattern''&lt;br /&gt;
|-&lt;br /&gt;
|''Evaluate evidence request (DP)''&lt;br /&gt;
|''See intermediation pattern''&lt;br /&gt;
|''See intermediation pattern''&lt;br /&gt;
|-&lt;br /&gt;
|''Establish subject identity (DP)''&lt;br /&gt;
|''See intermediation pattern''&lt;br /&gt;
|''See intermediation pattern''&lt;br /&gt;
|-&lt;br /&gt;
|''Communicate non-availability of OOP (DP)''&lt;br /&gt;
|''See intermediation pattern''&lt;br /&gt;
|''See intermediation pattern''&lt;br /&gt;
|-&lt;br /&gt;
|''Extract evidence (DP)''&lt;br /&gt;
|''See intermediation pattern''&lt;br /&gt;
|''See intermediation pattern''&lt;br /&gt;
|-&lt;br /&gt;
|''Communicate non-availability or Delay of evidence (DP)''&lt;br /&gt;
|''See intermediation pattern''&lt;br /&gt;
|''See intermediation pattern''&lt;br /&gt;
|-&lt;br /&gt;
|''Establish non-availability of OOP (DC)''&lt;br /&gt;
|''See intermediation pattern''&lt;br /&gt;
|''See intermediation pattern''&lt;br /&gt;
|-&lt;br /&gt;
|''Compose evidence response (DP)''&lt;br /&gt;
|''See intermediation pattern''&lt;br /&gt;
|''See intermediation pattern''&lt;br /&gt;
|-&lt;br /&gt;
|''Transfer evidence (DP)''&lt;br /&gt;
|''See intermediation pattern''&lt;br /&gt;
|''See intermediation pattern''&lt;br /&gt;
|-&lt;br /&gt;
|''Forward evidence (DC)''&lt;br /&gt;
|''See intermediation pattern''&lt;br /&gt;
|''See intermediation pattern''&lt;br /&gt;
|-&lt;br /&gt;
|Evaluate evidence (DC)&lt;br /&gt;
|Assess Evidence&lt;br /&gt;
|eProcedure Backoffice Back-end&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
===Component description===&lt;br /&gt;
The following table lists the components indicated in the image above. Per component a short description of its use is given, by which role the component is used (i.e. DE, DR, DT, DO) and whether the component is MS specific or common functionality.  &lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|'''Component'''&lt;br /&gt;
|'''Short description of its use'''&lt;br /&gt;
|'''Role'''&lt;br /&gt;
|'''Genericness*'''&lt;br /&gt;
|'''Changes for 2nd iteration piloting'''&lt;br /&gt;
|-&lt;br /&gt;
|eProcedure Back-office Backend&lt;br /&gt;
|This component handles all backoffice functionality for the eProcedure. For the Lookup pattern it:&lt;br /&gt;
&lt;br /&gt;
*translates the required evidence to the canonical evidence to request&lt;br /&gt;
*requests the canonical evidence to the MS DE4A connector&lt;br /&gt;
*receives the evidence (or error)&lt;br /&gt;
*processes the evidence (update local data store, process possible impact on service provided to the company / general fraud detection or prevention).&lt;br /&gt;
&lt;br /&gt;
|DE&lt;br /&gt;
|specific&lt;br /&gt;
|This new functionality needs to be designed and developed by each of the participating DE's.&lt;br /&gt;
|-&lt;br /&gt;
|Back-office to OOP TS&lt;br /&gt;
|Interface for connecting the DE's backoffice with the OOP TS for:&lt;br /&gt;
*requesting evidence by Lookup&lt;br /&gt;
&lt;br /&gt;
Just like the portal to OOP TS interface (as described in the DBA first iteration solution architecture), Member States may choose to implement this interface in a generic way to bridge national OOP protocols to DE4A datamodel at one single place. Furthermore, Member States may choose to integrate both interfaces (portal to OOP TS and backoffice to OOP TS) in one single interface. &lt;br /&gt;
| DR&lt;br /&gt;
|specific&lt;br /&gt;
|Needs to be developed and implemented for the second iteration.&lt;br /&gt;
May be partial re-use of the portal to OOP TS interface. &lt;br /&gt;
|-&lt;br /&gt;
|DE4A Connector&lt;br /&gt;
|Taking care of eDelivery and IDK interfacing, shielding DR and DT from complexities and facilitating ease of implementation.&lt;br /&gt;
&lt;br /&gt;
Error handling and logging.&lt;br /&gt;
|DR, DT&lt;br /&gt;
|common&lt;br /&gt;
|No changes expected. &lt;br /&gt;
Double check that the component as deployed for the intermediation pattern can be used  without change. &lt;br /&gt;
|-&lt;br /&gt;
|IDK&lt;br /&gt;
|DE4A playground IDK: a web application for locating the service to reach out to.&lt;br /&gt;
|DR, DT&lt;br /&gt;
|common&lt;br /&gt;
|No changes expected. &lt;br /&gt;
Double check that the component as deployed for the intermediation pattern can be used  without change. &lt;br /&gt;
|-&lt;br /&gt;
|SMP&lt;br /&gt;
|For each subscription request/response, information on the receivers Access Point (URL) and its certificates are needed. Each member state hosts an SMP for this purpose (note: for testing one single centrally hosted DE4A SMP will be used). Before sending a request or response, the sending party queries the SMP of the receiver to get this info. &lt;br /&gt;
|DR, DT&lt;br /&gt;
|common&lt;br /&gt;
|None expected.&lt;br /&gt;
|-&lt;br /&gt;
|eDelivery access Point&lt;br /&gt;
|This component – also referred to as eDelivery AS4 gateway – handles the secure transfer of the data, including encryption and decryption as well as signing/sealing and validating signatures/seals.&lt;br /&gt;
|DR, DT&lt;br /&gt;
|common&lt;br /&gt;
|No changes expected. &lt;br /&gt;
&lt;br /&gt;
Double check that the component as deployed for the intermediation pattern can be used without change. &lt;br /&gt;
|-&lt;br /&gt;
|DNS &amp;amp; SML&lt;br /&gt;
|As there are multiple SMP’s, the sending  party needs to know where to find the SMP of the receiver to get the actual  metadata. This location can be found in the centrally CEF-hosted DNS, that will be queried by the access point of the sending member state. &lt;br /&gt;
&lt;br /&gt;
DNS entries will be created from the registration of SMP’s: the SML, which is also centrally hosted by CEF. &lt;br /&gt;
| Central&lt;br /&gt;
|central&lt;br /&gt;
|None expected.&lt;br /&gt;
|-&lt;br /&gt;
|Data Service&lt;br /&gt;
|The webservice of the data provider that will output the evidence requested.&lt;br /&gt;
|DO&lt;br /&gt;
|specific&lt;br /&gt;
|None expected.&lt;br /&gt;
|-&lt;br /&gt;
|Data source to OOP TS Interface&lt;br /&gt;
|Interface for connecting the data service with the OOP TS (IM &amp;amp; LKP).&lt;br /&gt;
|DO, DT&lt;br /&gt;
|specific&lt;br /&gt;
|None expected.&lt;br /&gt;
|}&lt;br /&gt;
&amp;lt;nowiki&amp;gt;*&amp;lt;/nowiki&amp;gt;genericness: specific: to be developed, deployed and hosted by MS; common: to be developed by WP5 and deployed and hosted by MS; central: to be developed, deployed and hosted by CEF&lt;br /&gt;
&lt;br /&gt;
===Functional requirements===&lt;br /&gt;
The table below presents the requirements that the components involved need to implement.&lt;br /&gt;
   &lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|'''Component'''&lt;br /&gt;
|'''Nr'''&lt;br /&gt;
|'''DBA requirement'''&lt;br /&gt;
|'''Comment'''&lt;br /&gt;
|-&lt;br /&gt;
|eProcedure Back-office&lt;br /&gt;
|1&lt;br /&gt;
|Once the eProcedure backoffice logic has assessed the notification and has concluded one or more evidences (or updates to evidences) need to be requested, the back-office should be able to send the evidence request to the OOP TS interface.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Please note, in case of multiple data owners in one Member State supporting the required evidence type, the Data evaluator needs to be aware which one to contact (as there is no possibility to ask the user). Hence, after processing the initial evidence in the intermediation pattern, it needs to store the data owner ('participant') to contact for updates. In the DBA pilot there will be only one data owner per Member State, so there is no need to store the participant at the DE.&lt;br /&gt;
|The evidence request will be the same or similar to the request of the intermediation pattern.&lt;br /&gt;
|-&lt;br /&gt;
|Back-office to OOP TS&lt;br /&gt;
|&lt;br /&gt;
|no Lookup-specific requirements&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|DE4A connector&lt;br /&gt;
|&lt;br /&gt;
|no Lookup-specific requirements&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|IDK&lt;br /&gt;
|&lt;br /&gt;
|no Lookup-specific requirements&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|SMP&lt;br /&gt;
|&lt;br /&gt;
|no Lookup-specific requirements&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|eDelivery Access Point&lt;br /&gt;
|&lt;br /&gt;
|no Lookup-specific requirements&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|DNS &amp;amp; SML&lt;br /&gt;
|&lt;br /&gt;
|no Lookup-specific requirements&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|Data service&lt;br /&gt;
|&lt;br /&gt;
|no Lookup-specific requirements&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|Data source to OOP TS Interface&lt;br /&gt;
|&lt;br /&gt;
|no Lookup-specific requirements&lt;br /&gt;
|&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
The table below presents the requirements for the DE and DO mocks.&lt;br /&gt;
&lt;br /&gt;
* The DE mock should mock the eProcedure Back-office Backend.&lt;br /&gt;
* The DO mock should mock the data service.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|'''Component'''&lt;br /&gt;
|'''Nr'''&lt;br /&gt;
|'''DBA requirement'''&lt;br /&gt;
|'''Comment'''&lt;br /&gt;
|-&lt;br /&gt;
|DE mock&lt;br /&gt;
|1&lt;br /&gt;
|no Lookup-specific requirements&lt;br /&gt;
Same functionality as DE mock for Intermediation pattern.&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|DO mock&lt;br /&gt;
|1&lt;br /&gt;
|no Lookup-specific requirements&lt;br /&gt;
Same functionality as DO mock for Intermediation pattern.&lt;br /&gt;
|&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
===Component deployment===&lt;br /&gt;
*See intermediation pattern.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Expectations for WP3:&lt;br /&gt;
&lt;br /&gt;
*analyse and design authorisation controller for the Lookup pattern (out of scope for piloting)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Expectation for WP5:&lt;br /&gt;
&lt;br /&gt;
*double check to ensure the common components can be re-used from the intermediation pattern without any change.&lt;br /&gt;
&lt;br /&gt;
===Logical interfaces===&lt;br /&gt;
The expected logical interfaces remain unchanged. &lt;br /&gt;
==Solution architecture for Intermediation Pattern==&lt;br /&gt;
The solution architecture for the intermediation pattern has been designed in the first pilot iteration. Please refer to [[DBA D4.6 Pilot planning|D4.6 Pilot planning]] for this architecture (not included in the wiki yet). &lt;br /&gt;
&lt;br /&gt;
The solution architecture remains unchanged, except for two additional requirements for the eProcedure portal that have been introduced by the S&amp;amp;N pattern. &lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|'''Component'''&lt;br /&gt;
|'''Nr'''&lt;br /&gt;
|'''DBA requirement'''&lt;br /&gt;
|'''Comment'''&lt;br /&gt;
|-&lt;br /&gt;
| rowspan=&amp;quot;2&amp;quot; |eProcedure portal&lt;br /&gt;
|1&lt;br /&gt;
|For the S&amp;amp;N pattern the logic of the eProcedure portal needs to be extended to initiate a subscription (start of S&amp;amp;N pattern). Whether a subscription is needed after processing the evidence is depending on the rules and regulation the data evaluator implements.&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|2&lt;br /&gt;
|For the S&amp;amp;N pattern the logic of the eProcedure portal might need to be adapted to include rules and texts for informing the user on subscriptions &amp;amp; possibly notifications.&lt;br /&gt;
&lt;br /&gt;
As S&amp;amp;N is out of scope of the SDGR, this informative step is not part of the explicit request process. However, the user should be informed of subscriptions. &lt;br /&gt;
| Has no priority in piloting DBA S&amp;amp;N. Might be implemented by the DE, but it doesn't need to.&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
==Appendix: archimate component diagrams==&lt;br /&gt;
&lt;br /&gt;
===Solution architecture for DBA authentication and powers validation===&lt;br /&gt;
&lt;br /&gt;
===Solution architecture for Subscription &amp;amp; Notification pattern and Lookup pattern===&lt;br /&gt;
TODO merge AC's and tailor to pilot increment 2.&lt;/div&gt;</summary>
		<author><name>Ictu mavi.cristache</name></author>
	</entry>
	<entry>
		<id>https://wiki.de4a.eu/index.php?title=DBA_Use_case_definition&amp;diff=3698</id>
		<title>DBA Use case definition</title>
		<link rel="alternate" type="text/html" href="https://wiki.de4a.eu/index.php?title=DBA_Use_case_definition&amp;diff=3698"/>
		<updated>2021-10-26T06:40:41Z</updated>

		<summary type="html">&lt;p&gt;Ictu mavi.cristache: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;__NUMBEREDHEADINGS__&lt;br /&gt;
== Partners ==&lt;br /&gt;
'''Austria'''&lt;br /&gt;
&lt;br /&gt;
'''Federal Ministry for Digital and Economic Affairs (BMDW)''': The tasks of the Federal Ministry for Digital and Economic Affairs include the comprehensive offerings of the e-government sector, the overall coordination of e-government as well as the digital transformation of the economy and society in Austria. The tasks of the Ministry are performed by various Centres and Directorates General with differing priorities (Economic Policy, Innovation &amp;amp; Technology; External Trade Policy &amp;amp; European Integration, etc.).&lt;br /&gt;
&lt;br /&gt;
'''The Austrian Federal Computing Centre (BRZ):''' The Austrian Federal Computing Centre (short: BRZ as abbreviated from the German name Bundesrechenzentrum) is the market-leading technology partner of the public sector in Austria. As such, BRZ has developed and implemented more than 400 IT applications and e-government solutions. BRZ also operates one of Austria’s largest data centres, guarding the country’s precious treasury of data.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Netherlands'''&lt;br /&gt;
&lt;br /&gt;
'''Netherlands Enterprise Agency (RVO):''' RVO is the department of the Ministry of Economic Affairs and Climate Policy that participates in the DE4A project. This Agency encourages entrepreneurs in sustainable, agrarian, innovative and international business. It helps with grants, finding business partners, know-how and compliance with laws and regulations. The aim is to improve opportunities for entrepreneurs and strengthen their position. The activities of the Agency are commissioned by the various Dutch ministries and the European Union. The Netherlands Enterprise Agency focuses on providing services to entrepreneurs. It aims to make it easier to do business using smart organisation and digital communication. The Agency works in The Netherlands and abroad with governments, knowledge centres, international organisations and countless other partners.&lt;br /&gt;
&lt;br /&gt;
'''Kamer van Koophandel (KVK):''' Netherlands Chamber of Commerce officially registers companies and gives them advice and support. The main task of the Chamber of Commerce is to keep the Commercial Register (the business register). In the Netherlands registration in the Commercial Register is compulsory for every company and almost every legal entity. This means that the register is able to provide reliable answers to such questions as: Does the company I want to do business with actually exist? Is the person I am dealing with actually an authorised signatory? What has happened to the company I used to do business with?&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Sweden'''&lt;br /&gt;
&lt;br /&gt;
'''Skatteverket (SKV):''' The main functions of the Swedish tax agency (Skatteverket) are: Taxes, Population registration and Estate inventories. Skatteverket is accountable to the government but operates as an autonomous public authority. This means that the government has no influence over the tax affairs of individuals or businesses. &lt;br /&gt;
&lt;br /&gt;
'''Bolagsverket (BVE):''' The Swedish Companies Registration Office (Bolagsverket) creates the conditions needed for establishing trust within the business sector. BVE’s primary role is to register company information and make it available, which contributes value to society. BVE will provide good conditions for business. BVE wants to create a good infrastructure for growth and give enterprising individuals the indications they need for achieving their dreams. BVE is working with other government agencies in order to reach these goals. Bolagsverket registers new companies, changes in company information and annual reports. Persons can also search for and purchase company information from BVE’s registers. Working together with others, BVE helps to make life simpler for companies and those doing business.&lt;br /&gt;
&lt;br /&gt;
The agency for digital government (DIGG): DIGG is a new government authority, created to think creatively, address new challenges and identify new opportunities, started in 2018. Several reports and inquiries have concluded that governance of digital administration is complex and overly fragmented. DIGG has collective responsibility for these issues in order to achieve more transparent governance toward the goals set by the central government. DIGG will serve as a hub for digitalization of the public sector.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Romania'''&lt;br /&gt;
&lt;br /&gt;
'''CIO Office:''' The CIO Office is part of the General Secretariat of the Government (aka the Prime Minister’s Office). It coordinates the IT&amp;amp;C of the Romanian central public administration, establishes the architecture of the IT&amp;amp;C systems, oversees the investments in IT&amp;amp;C and cooperates in the field of cybersecurity with the other law enforcement, defence and intelligence agencies. The CIO Office will coordinate Romania’s participation in the pilot. &lt;br /&gt;
&lt;br /&gt;
'''Oficiul National al Registrului Comertului (ONRC):''' The National Trade Register Office (short: ONRC/RO an NTRO/EN) is a public institution with legal personality, organized under the Ministry of Justice, financed entirely from the state budget through the Ministry of Justice. NTRO is organised with 42 local offices (county seat) without legal personality and works beside tribunals. NTRO's vision is to contribute to the development of the business environment in Romania by providing quality public services, flexible and geared to the specific needs of applicants. The main mission of the National Trade Register Office (NTRO) is in the public service of keeping the trade registry and to perform legal acts and facts advertising entrepreneurs, and performing the procedure for summoning and publicity of insolvency proceedings.&lt;br /&gt;
&lt;br /&gt;
== Pilot scenarios ==&lt;br /&gt;
&lt;br /&gt;
* '''Pilot scenario DBA1: USP.gv.at''': USP (Business service portal) includes several services (starting a business online) that are not restricted to Austrian companies. In order to qualify for the service, the company must provide the necessary data and needs an entry in one of the registers. The stored company data must be kept up to date. This scenario entails a non-Austrian company that applies for a service carried out by usp.gv.at. Currently, this is a semi-automated process, due to a necessary application process to identify organisation and the approval of the powers (of representation). In the pilot process, the company can apply for these services through an easy online form, which will trigger an automatic registration to most of Austria´s online services. Additionally, as best-effort, Austria will make this application process fully automated, so the company does not have to supply information to USP that is already known to a data provider in another Member State (the ‘native’ country of the business) in application of the Once-Only Principle. In either case, USP is able to retrieve this information from the data provider and keep the information up to date. The minimum goal of the scenario is to digitalise this process. The maximum goal is to implement a fully automated process.&lt;br /&gt;
* '''Pilot scenario DBA4: MijnRVO.nl:''' RVO offers several services for companies that are not restricted to Dutch companies. In order to qualify for the service, the company must provide the necessary data. Besides the specific data required to qualify for the service, RVO also requires general data of the company itself, for identification, communication and compliance purposes. RVO stores this company data in a central (‘customer’) registry that is used for most RVO services. The stored company data must be kept up to date. This scenario entails a non-Dutch company that applies for a service carried out by RVO.nl. In this process, the company does not have to supply information to RVO that is already known to the data provider in a Member State (the ‘native’ country of the business) in application of the Once-Only Principle. RVO.nl is able to retrieve this information from the data provider and keep the information up to date.&lt;br /&gt;
* '''Pilot scenario DBA5: Verksamt.se (PSC):''' Companies that want to do business in Sweden will be registered by the Swedish Companies Registration Office through the Swedish Point of Single Contact Verksamt.se. The portal presents companies with information and e-services. There is no information stored within the portal. The source of company information will be the respective authority. There is an opportunity to do a tax registration, with underlying processes such as registering the company at Skatteverket, registering as an employer, paying VAT, applying for F-tax and so on. It is also possible to register a branch of a foreign company, by using the service provided by Bolagsverket. Verksamt.se is designed to provide a unified process for the foreign company to be able to register a branch and then make a tax registration in Sweden, depending on how the company intends to conduct business operations in Sweden. Verksamt.se also supports foreign companies, whether they conduct business from a permanent establishment in Sweden or only want to register for tax purpose (not register a branch), for selected processes e.g. to register as an employer or F-tax. F-tax can be applied for without liability to pay income tax, but serves as a proof that the company has no tax liabilities in the country of registration and is therefore considered serious.&lt;br /&gt;
* '''Pilot scenario DBA6: eService Layer at portal.onrc.ro:''' Companies wishing to do business in Romania will be registered by the National Trade Register Office. The registration of the company of a single trader, company or branch of a foreign company is done using the online service portal eService Layer at portal.onrc.ro and leads to the registration in the register of Romanian companies (ONRC). The registration also leads to registration with the Romanian tax agency - ANAF. As part of the registration with the tax agency, the company can (if applicable) register the permanent unit and register for VAT.&lt;br /&gt;
&lt;br /&gt;
== Use cases ==&lt;br /&gt;
&lt;br /&gt;
# '''Use case 1: Starting a business in another Member State'''. At the core of this use case is the fulfilment of procedural obligations to do business in another Member State, especially the initial registration of a company at an eProcedure portal (AT, NL and RO pilot scenarios), opening a branch and the assessment of tax duties in the destination Member State (in the Swedish pilot scenario). In this use case, a company representative authenticates to the eProcedure portal, registers the company at the portal and applies for a service.&lt;br /&gt;
# '''Use case 2: Doing business in another Member State.''' This use case focusses at assessing the consequence for active eServices in case of a business event, e.g. company goes bankrupt, company stops it’s activities, company merges, etc. The data consumer may subscribe to notifications on selected business events. In case such an event occurs, the data provider notifies the data consumer. The data consumer needs to assess the relevance of the notification. It can then for example request the updated data from the data provider or decide it doesn’t need any additional data. Furthermore, the data consumer may intervene in an active eService (e.g. stop periodical grants or impose a tax obligation). The data consumer may also use the notifications as input to a general fraud prevention and protection procedure. &lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|'''Pilot scenario #'''&lt;br /&gt;
|'''Pilot scenario short name'''&lt;br /&gt;
| colspan=&amp;quot;2&amp;quot; |'''Use case to pilot'''&lt;br /&gt;
|-&lt;br /&gt;
| &lt;br /&gt;
| &lt;br /&gt;
|'''UC1: starting a business in another Member State'''&lt;br /&gt;
|'''UC2: Doing business in another Member State'''&lt;br /&gt;
|-&lt;br /&gt;
|DBA1&lt;br /&gt;
|USP.gv.at&lt;br /&gt;
|x&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|DBA4&lt;br /&gt;
|MijnRVO.nl&lt;br /&gt;
|x&lt;br /&gt;
|x&lt;br /&gt;
|-&lt;br /&gt;
|DBA5&lt;br /&gt;
|Verksamt.se (PSC)&lt;br /&gt;
|x&lt;br /&gt;
|x&lt;br /&gt;
|-&lt;br /&gt;
|DBA6&lt;br /&gt;
|eService Layer at  portal.onrc.ro&lt;br /&gt;
|x&lt;br /&gt;
|x&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
== Interaction patterns ==&lt;br /&gt;
&lt;br /&gt;
The use cases implement three [[Reference Interaction Patterns|interaction patterns]]:&lt;br /&gt;
&lt;br /&gt;
# '''[[Intermediation Pattern|The intermediation pattern]]''': for fetching company data at the request of the user from the business register directly.&lt;br /&gt;
# '''[[Subscription and Notification Pattern|The subscription and notification pattern]]''': for allowing data consumers to subscribe to updates on company data and to receive notifications of changes in company data.&lt;br /&gt;
# '''[[Lookup Pattern|The lookup pattern]]''': for providing a light weight alternative to the intermediation pattern for fetching (possibly updated) company data from business registers with direct service calls. This pattern focusses on high frequency, highly standardised data requests to data sources which the data consumer is familiar to.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
The diagram below shows the mapping of the use cases to the interaction patterns.&lt;br /&gt;
[[File:Use case to interaction pattern mapping.png|left|thumb|377x377px]]&lt;/div&gt;</summary>
		<author><name>Ictu mavi.cristache</name></author>
	</entry>
	<entry>
		<id>https://wiki.de4a.eu/index.php?title=Semantic_Interoperability_Solutions&amp;diff=3556</id>
		<title>Semantic Interoperability Solutions</title>
		<link rel="alternate" type="text/html" href="https://wiki.de4a.eu/index.php?title=Semantic_Interoperability_Solutions&amp;diff=3556"/>
		<updated>2021-10-14T07:53:23Z</updated>

		<summary type="html">&lt;p&gt;Ictu mavi.cristache: Created page with &amp;quot;Wat is de bedoeling van deze pagina...&amp;quot;&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Wat is de bedoeling van deze pagina...&lt;/div&gt;</summary>
		<author><name>Ictu mavi.cristache</name></author>
	</entry>
	<entry>
		<id>https://wiki.de4a.eu/index.php?title=MediaWiki:Sidebar&amp;diff=3554</id>
		<title>MediaWiki:Sidebar</title>
		<link rel="alternate" type="text/html" href="https://wiki.de4a.eu/index.php?title=MediaWiki:Sidebar&amp;diff=3554"/>
		<updated>2021-10-14T07:46:46Z</updated>

		<summary type="html">&lt;p&gt;Ictu mavi.cristache: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;* navigation&lt;br /&gt;
** mainpage|mainpage-description&lt;br /&gt;
** recentchanges-url|recentchanges&lt;br /&gt;
** randompage-url|randompage&lt;br /&gt;
** helppage|help-mediawiki&lt;br /&gt;
&lt;br /&gt;
*DE4A Documentation&lt;br /&gt;
**Pilots|Pilots&lt;br /&gt;
**Reference Architecture|Reference Architecture&lt;br /&gt;
**Library of components and building blocks|Components and building blocks&lt;br /&gt;
**DE4A Solutions|DE4A Solutions&lt;br /&gt;
&lt;br /&gt;
*Other&lt;br /&gt;
**Getting started|Getting started&lt;br /&gt;
**Special:ListFiles|Files&lt;br /&gt;
**Glossary|Glossary&lt;br /&gt;
&lt;br /&gt;
* SEARCH&lt;br /&gt;
* TOOLBOX&lt;br /&gt;
* LANGUAGES&lt;/div&gt;</summary>
		<author><name>Ictu mavi.cristache</name></author>
	</entry>
	<entry>
		<id>https://wiki.de4a.eu/index.php?title=Library_of_components_and_building_blocks&amp;diff=3521</id>
		<title>Library of components and building blocks</title>
		<link rel="alternate" type="text/html" href="https://wiki.de4a.eu/index.php?title=Library_of_components_and_building_blocks&amp;diff=3521"/>
		<updated>2021-10-07T07:46:42Z</updated>

		<summary type="html">&lt;p&gt;Ictu mavi.cristache: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This page contains the collection of technical and semantic common components and candidate Building Blocks that are relevant for eGovernment interoperability in general and digital-by-default procedures and the Once-only Principle in particular. The classification of this library follows the DE4A [[Reference Architecture]], starting on the highest level of architecture components: the Application collaborations. These Application collaborations are aggregations of Application components, Data objects and Interfaces. You will find on each Application component pages a list of relevant DE4A common components, candidate Building Blocks (e.g. CEF) and memberstate solutions that jointly or alternatively realize that Application component. &lt;br /&gt;
&lt;br /&gt;
=== Application collaborations ===&lt;br /&gt;
* [[eProcedure Portal]]&lt;br /&gt;
* [[Information Desk]]&lt;br /&gt;
* [[Evidence Interchange Management]]&lt;br /&gt;
* [[Trust Architecture]]&lt;br /&gt;
* [[Data Logistics]]&lt;br /&gt;
* [[Evidence Portal]]&lt;br /&gt;
* [[Evidence Retrieval]]&lt;br /&gt;
* [[Authority Agent]]&lt;br /&gt;
* [[User Agent]]&lt;br /&gt;
* [[Cross-border Subscriptions]]&lt;br /&gt;
* [[EProcedure Back-office]]&lt;br /&gt;
&lt;br /&gt;
=== Building blocks (BB) assessment ===&lt;br /&gt;
The reference architecture description on conceptional/functional level is brought together with a catalogue of candidate building blocks mapped to required Application Services that they are intended to deliver in the context of each pilot. Gaps are identified that need common components and semantic solutions to be developed by WP5 and WP3 respectively.&lt;br /&gt;
&lt;br /&gt;
The BB assessment takes place in two phases:&lt;br /&gt;
&lt;br /&gt;
# In [[Building Blocks|the first phase]], as part of the PSA 1st iteration, the approach assessment of the BBs was elaborated and a quick scan was performed.&lt;br /&gt;
# In the second phase, after the Pilot's implementation and usage of some of the BBs, the assessment will be continued.&lt;/div&gt;</summary>
		<author><name>Ictu mavi.cristache</name></author>
	</entry>
	<entry>
		<id>https://wiki.de4a.eu/index.php?title=Library_of_components_and_building_blocks&amp;diff=3520</id>
		<title>Library of components and building blocks</title>
		<link rel="alternate" type="text/html" href="https://wiki.de4a.eu/index.php?title=Library_of_components_and_building_blocks&amp;diff=3520"/>
		<updated>2021-10-07T07:46:24Z</updated>

		<summary type="html">&lt;p&gt;Ictu mavi.cristache: Created page with &amp;quot;== Library of components and  building blocks ==  This section contains the collection of technical and semantic common components and candidate Building Blocks that are relev...&amp;quot;&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Library of components and  building blocks ==&lt;br /&gt;
&lt;br /&gt;
This section contains the collection of technical and semantic common components and candidate Building Blocks that are relevant for eGovernment interoperability in general and digital-by-default procedures and the Once-only Principle in particular. The classification of this library follows the DE4A [[Reference Architecture]], starting on the highest level of architecture components: the Application collaborations. These Application collaborations are aggregations of Application components, Data objects and Interfaces. You will find on each Application component pages a list of relevant DE4A common components, candidate Building Blocks (e.g. CEF) and memberstate solutions that jointly or alternatively realize that Application component. &lt;br /&gt;
&lt;br /&gt;
=== Application collaborations ===&lt;br /&gt;
* [[eProcedure Portal]]&lt;br /&gt;
* [[Information Desk]]&lt;br /&gt;
* [[Evidence Interchange Management]]&lt;br /&gt;
* [[Trust Architecture]]&lt;br /&gt;
* [[Data Logistics]]&lt;br /&gt;
* [[Evidence Portal]]&lt;br /&gt;
* [[Evidence Retrieval]]&lt;br /&gt;
* [[Authority Agent]]&lt;br /&gt;
* [[User Agent]]&lt;br /&gt;
* [[Cross-border Subscriptions]]&lt;br /&gt;
* [[EProcedure Back-office]]&lt;br /&gt;
&lt;br /&gt;
=== Building blocks (BB) assessment ===&lt;br /&gt;
The reference architecture description on conceptional/functional level is brought together with a catalogue of candidate building blocks mapped to required Application Services that they are intended to deliver in the context of each pilot. Gaps are identified that need common components and semantic solutions to be developed by WP5 and WP3 respectively.&lt;br /&gt;
&lt;br /&gt;
The BB assessment takes place in two phases:&lt;br /&gt;
&lt;br /&gt;
# In [[Building Blocks|the first phase]], as part of the PSA 1st iteration, the approach assessment of the BBs was elaborated and a quick scan was performed.&lt;br /&gt;
# In the second phase, after the Pilot's implementation and usage of some of the BBs, the assessment will be continued.&lt;/div&gt;</summary>
		<author><name>Ictu mavi.cristache</name></author>
	</entry>
	<entry>
		<id>https://wiki.de4a.eu/index.php?title=Talk:Doing_Business_Abroad_Pilot&amp;diff=3505</id>
		<title>Talk:Doing Business Abroad Pilot</title>
		<link rel="alternate" type="text/html" href="https://wiki.de4a.eu/index.php?title=Talk:Doing_Business_Abroad_Pilot&amp;diff=3505"/>
		<updated>2021-10-01T10:51:12Z</updated>

		<summary type="html">&lt;p&gt;Ictu mavi.cristache: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Using Talk Pages on the wiki ==&lt;br /&gt;
&lt;br /&gt;
I am placing an example comment here today. More information about adding comments here: https://www.mediawiki.org/wiki/Help:Talk_pages [[User:Ictu mavi.cristache|Ictu mavi.cristache]] ([[User talk:Ictu mavi.cristache|talk]]) 12:49, 1 October 2021 (CEST)&lt;br /&gt;
&lt;br /&gt;
: I am now replying to my own comment. [[User:Ictu mavi.cristache|Ictu mavi.cristache]] ([[User talk:Ictu mavi.cristache|talk]]) 12:51, 1 October 2021 (CEST)&lt;/div&gt;</summary>
		<author><name>Ictu mavi.cristache</name></author>
	</entry>
	<entry>
		<id>https://wiki.de4a.eu/index.php?title=Talk:Doing_Business_Abroad_Pilot&amp;diff=3504</id>
		<title>Talk:Doing Business Abroad Pilot</title>
		<link rel="alternate" type="text/html" href="https://wiki.de4a.eu/index.php?title=Talk:Doing_Business_Abroad_Pilot&amp;diff=3504"/>
		<updated>2021-10-01T10:49:54Z</updated>

		<summary type="html">&lt;p&gt;Ictu mavi.cristache: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Using Talk Pages on the wiki ==&lt;br /&gt;
&lt;br /&gt;
I am placing an example comment here today. [[User:Ictu mavi.cristache|Ictu mavi.cristache]] ([[User talk:Ictu mavi.cristache|talk]]) 12:49, 1 October 2021 (CEST)Mavi&lt;/div&gt;</summary>
		<author><name>Ictu mavi.cristache</name></author>
	</entry>
	<entry>
		<id>https://wiki.de4a.eu/index.php?title=Talk:Doing_Business_Abroad_Pilot&amp;diff=3503</id>
		<title>Talk:Doing Business Abroad Pilot</title>
		<link rel="alternate" type="text/html" href="https://wiki.de4a.eu/index.php?title=Talk:Doing_Business_Abroad_Pilot&amp;diff=3503"/>
		<updated>2021-10-01T10:47:13Z</updated>

		<summary type="html">&lt;p&gt;Ictu mavi.cristache: Created page with &amp;quot;Mavi: I am placing an example comment here today.&amp;quot;&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Mavi: I am placing an example comment here today.&lt;/div&gt;</summary>
		<author><name>Ictu mavi.cristache</name></author>
	</entry>
	<entry>
		<id>https://wiki.de4a.eu/index.php?title=Building_Blocks&amp;diff=3005</id>
		<title>Building Blocks</title>
		<link rel="alternate" type="text/html" href="https://wiki.de4a.eu/index.php?title=Building_Blocks&amp;diff=3005"/>
		<updated>2021-07-15T16:41:58Z</updated>

		<summary type="html">&lt;p&gt;Ictu mavi.cristache: /* Recommendations and Gap Analysis */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The purpose of the Building Blocks (BB) assessment is to assess the suitability of the BB identified and catalogued in Task 1.5 for use within the DE4A project. Thus, it bridges outputs from WP1 and requirements from WP4 to provide input for the technical, operational and administrative considerations in the architectural assessments carried out here. Over 40 BB have been considered for this assessment, 31 of which are assessed at the first phase of this work. The results of the assessment show that there is a mature and acceptable stock of solution building blocks that can be considered as potential candidates for implementation by the pilots, either in their entirety or partially, with the needed upgrades.&lt;br /&gt;
&lt;br /&gt;
== Theoretical background ==&lt;br /&gt;
&lt;br /&gt;
=== Objectives and scope ===&lt;br /&gt;
To reach the goal outlined above, this section delves into the architectural evaluation of the building blocks catalogued as useful for DE4A. It is important to note that the term “building block” in the context of this assessment refers to a Solution Building Block in TOGAF sense. &lt;br /&gt;
&lt;br /&gt;
The most important step in assessing the BB is determining the methodology that would support a common description framework of the BB, while providing means for determining the quantitative and/or qualitative evaluation criteria of the considered BB. The outcome of the assessment is a succinct list of recommendations for BB use by the pilots in WP4. In addition to defining the methodology, a gap analysis is performed based on both the pilots’ requirements and the common description framework of the BB, considering the results from the assessment, the project requirements and the common PSA principles. The overall process of conceptual considerations, empirical evaluation, gap analysis and piloting recommendations are denoted as a DE4A generic methodology for architecture building blocks evaluation.&lt;br /&gt;
&lt;br /&gt;
=== Available methodologies ===&lt;br /&gt;
In order to provide continuity and justification of the methodology that is being developed, we first outline and assess the suitability of the currently available methodologies in view of the implementation context and the objectives of the DE4A project. To that end, both generic EU/EC assessment methodologies and past LSP project-specific methodologies are considered.&lt;br /&gt;
&lt;br /&gt;
==== Common assessment method for standards and specifications (CAMSS) ====&lt;br /&gt;
[https://ec.europa.eu/isa2/solutions/camss_en CAMSS] is part of the ISA² interoperability solutions evaluation toolkit for public administrations, businesses and citizens. It provides a method to assist in the assessment of ICT standards and specifications. The main objective of CAMSS is achieving interoperability and avoiding vendor lock-in. In that sense, CAMSS criteria evaluate (among other things) the openness of standards and specifications. This is done by employing the CAMSS tools and adapting the evaluation according to the needs of an individual Member State.&lt;br /&gt;
&lt;br /&gt;
In the context of DE4A, relying solely on CAMSS does not provide the means for BB suitability and gap analysis in relation to the piloting needs. Moreover, it does not provide any selection criteria or a taxonomy for consistent mapping of the different BB onto a common comparable framework.&lt;br /&gt;
&lt;br /&gt;
==== Past project-specific methodologies ====&lt;br /&gt;
'''eSENS'''&lt;br /&gt;
&lt;br /&gt;
eSENS has developed its own methodology for BB assessment, which is mainly an adaptation of CAMSS and Asset Description Metadata Schema (ADMS), supported by inputs of the [https://web.archive.org/web/20200928232327/http://www.esens.eu/deliverables eSENS deliverable D6.1] (see Table 5 in [https://web.archive.org/web/20200928232327/http://www.esens.eu/deliverables eSENS D3.1]). Its objective is to propose a documentation of format and defining criteria for the maturity and sustainability assessment of building blocks. The overall framework consists of three steps: 1) The Consideration step; 2) The Assessment step; and 3) The Recommendation step and produces a list of assessment criteria to be used for BB evaluation. These criteria, however, are very general and not architecture-specific – their applicability is valid and valuable only if used in collaboration with the legal, business, organizational, technical and implementation team.&lt;br /&gt;
&lt;br /&gt;
It is important to note that the assessment methodology employed in eSENS is developed with a different aim from ours – its analysis and recommendations refer to the desired BB qualities that are needed to ensure meeting the maturity levels and the sustainability criteria envisaged by the project. Thus, although it produces guidelines for assessment, it does not provide concrete output in terms of actual scores, analysis and recommendations for BB. Moreover, it does not provide a comparable baseline when multiple BB have to be considered for the same pilot and it is based on the assumption that the existing BB represent the exhaustive list of possible solutions from which a suitable match should be chosen. In the case of DE4A, such an assumption does not hold, as there may be a case where a certain BB is not mature enough to be recommended for piloting but is also not to be completely disregarded either. More importantly, the methodology developed here is used for actual assessment and is to be fine-tuned at a later stage in connection to the general architecture lifecycle development.&lt;br /&gt;
&lt;br /&gt;
'''TOOP'''&lt;br /&gt;
&lt;br /&gt;
Like eSENS, the overall idea of the TOOP assessment methodology is to reuse existing frameworks and building blocks provided by CEF, eSENS, and other initiatives. First, an initial inventory of existing e- Government building blocks is proposed. Then, the principles of selection of building blocks for OOP applications are provided, together with high-level views of the architecture. Finally, an analysis of selected building blocks is done with respect to their relevance, applicability, sustainability, need for further development and external interfaces.&lt;br /&gt;
&lt;br /&gt;
The main criteria for inclusion of a building block in TOOP are:&lt;br /&gt;
&lt;br /&gt;
* The specific project requirements;&lt;br /&gt;
* The TOOP pilots’ needs;&lt;br /&gt;
* Usability in long-term applications (maintenance and support provided).&lt;br /&gt;
&lt;br /&gt;
As a result, the building blocks are categorized into three basic groups:&lt;br /&gt;
&lt;br /&gt;
# BB that provide capabilities needed by all or most TOOP Pilot Areas;&lt;br /&gt;
# BB that provide capabilities needed or probably needed by some TOOP Pilot Areas;&lt;br /&gt;
# BB that provide capabilities not needed by the TOOP Pilot Areas.&lt;br /&gt;
&lt;br /&gt;
TOOP’s criteria are tightly bound to the piloting needs, whereas the rationale behind their choice is OOP-specific rather than generic. The methodology here follows a similar line of reasoning, but differs in the conceptual framework, which is more formally defined and made reusable by other projects as well. &lt;br /&gt;
&lt;br /&gt;
==== ISA2 Interim Evaluation ====&lt;br /&gt;
The [https://ec.europa.eu/isa2/sites/isa/files/190613_synopsis_report.pdf interim evaluation] aimed to assess how well the ISA² Programme has performed since its start in 2016 and whether its existence continues to be justified. Based on stakeholders’ views, opinions and public consultation, it evaluated the implementation of the programme based on seven criteria and identified several points for improvement. &lt;br /&gt;
&lt;br /&gt;
The evaluation criteria considered were: Relevance (the alignment between the objectives of the programme and the current needs and problems experienced by stakeholders); Effectiveness (the extent to which the programme has achieved its objectives); Efficiency (the extent to which the programme’s objectives are achieved at a minimum cost); Coherence (the alignment between the programme and comparable EU initiatives as well as the overall EU policy framework); EU added value (the additional impacts generated by the programme, as opposed to leaving the subject matter in the hands of Member States); Utility (the extent to which the programme meets stakeholders’ needs); and Sustainability (the likelihood that the programme’s results will last beyond its completion).&lt;br /&gt;
&lt;br /&gt;
However, the interim evaluation does not provide a specific methodology – either in terms of criteria choice, or in terms of architectural or future piloting recommendations. Its value lies mainly in the identification of possible gaps that exist within the current EU architecture framework even prior to the implementation of the available building blocks. In that sense, the main recommendations for prospective actions are determined in awareness raising beyond national administrations; moving from user-centric to user-driven solutions; and working towards increased sustainability.&lt;br /&gt;
&lt;br /&gt;
Our work integrates the interim evaluation criteria even at the stage of cataloguing BB relevant in DE4A context. More importantly, it takes into consideration the methodological gaps identified in the assessment in terms of awareness, user-driven solutions and sustainability prescriptions and integrates specific technical, administrative and operational aspects in the recommendation’s extraction for the pilots. &lt;br /&gt;
&lt;br /&gt;
==== EAAF ====&lt;br /&gt;
The [https://obamawhitehouse.archives.gov/sites/default/files/omb/assets/fea_docs/OMB_EA_Assessment_Framework_v3_1_June_2009.pdf Enterprise Architecture Assessment Framework (EAAF)] assists the US government in the assessment and reporting of their enterprise architecture activity and maturity, as well as in the advancement of the use of enterprise architecture to guide political decisions on IT investments. In addition to providing the methods for the assessment, EAAF also identifies the measurement areas and criteria by which government agencies are to rely on the architecture to drive performance improvements. This is integrated into the so-called Performance Improvement Lifecycle, where points for improvement are identified and translated into specific actions.&lt;br /&gt;
&lt;br /&gt;
In that sense, the framework provides a good overall methodology for the assessment of DE4A BB. Following its guidelines, in order to perform the technical assessment, the architects, together with the relevant project partners (mainly from WP1 and WP4):&lt;br /&gt;
&lt;br /&gt;
* Identify and prioritize the BB considering the pilots’ needs and in view of the project goals and objectives;&lt;br /&gt;
* Determine specific methodological steps for gap analysis, using common or shared information assets and information technology assets;&lt;br /&gt;
* Quantify/qualify and assess the performance to verify compliance with pilots’ requirements and provide report on gap closure; and&lt;br /&gt;
* Assess feedback on the pilots’ performance in order to enhance the architecture and fine-tune the assessment methodology for future implementation decisions.&lt;br /&gt;
&lt;br /&gt;
=== Methodological considerations ===&lt;br /&gt;
The need to develop a generic methodology that integrates some aspects of the standardized methodologies, but does not rely on a single one, is based on several considerations: &lt;br /&gt;
&lt;br /&gt;
# The assessment methodologies currently available either focus on alignment of the BB specifications or are only concerned with the maturity of the solution provided by the building blocks; &lt;br /&gt;
# They do not provide a clear definition of the common principles for assessment;&lt;br /&gt;
# They do not allow for a phased-approach to the assessment and are applicable either for a single BB or for a finalized solution architecture (Note: Although EAAF prescribes the principles for a phased assessment, it does not delineate the phases explicitly and only gives a requirement for the overall outcome of the assessment). &lt;br /&gt;
&lt;br /&gt;
As a result, the architect is prevented from developing an assessment for multiple BB with varying levels of complexity and is also disabled to perform comparative evaluation for determining the best fit for a particular solution architecture. &lt;br /&gt;
&lt;br /&gt;
The methodology developed here is novel in that it addresses the points above and is also generic in the sense that it can be reused by other large-scale projects for similar purposes. It incorporates the assessment principles of existing standards-based methodologies (like CAMSS and EAAF) taking into account the architecture feasibility and sustainability, but it also generalizes these principles over the context of implementation required by DE4A.&lt;br /&gt;
&lt;br /&gt;
== Methodology ==&lt;br /&gt;
In order to account for both the piloting recommendations criteria and the performance assessment criteria, the overall methodology requires a phased approach. Therefore, it consists of two phases:&lt;br /&gt;
&lt;br /&gt;
I) The first phase takes stock of the entire list of BB that can have potential use in the project and as part of the piloting. Then, a conceptual and an empirical framework for evaluation is developed – the former enables the gap analysis of the BB, whereas the latter allows for qualitative and comparative analysis of the BB, as well as extraction of concrete recommendations for piloting. The first phase essentially corresponds to the first three points of the EAAF.&lt;br /&gt;
&lt;br /&gt;
II) The second phase will account for the complete list of project artefacts and will provide empirical validation for the results and recommendations from the first phase. In addition, reassessment of the previous gaps will be performed. This phase will mainly be realized in close collaboration with the pilots: direct feedback via surveys and questionnaires on BB performance will be obtained and the initial conceptual framework will be fine-tuned accordingly. The second phase corresponds to the last point of the EAAF.&lt;br /&gt;
&lt;br /&gt;
=== Conceptual framework ===&lt;br /&gt;
In this section, we first catalogue the BB that are to be considered by the assessment. This step considers the output from D1.5 and establishes a relation to the internal project environment. Then we establish a common conceptualization of the key elements, which is based on the Digital service model, Section 2.2 of the Study on &amp;quot;The feasibility and scenarios for the long-term sustainability of the Large Scale Pilots”. With that, a relation to the external project environment is established. Finally, a basic assessment framework is developed to enable the grading of the BB from several maturity aspects: technical, administrative and operational. The output of the assessment will allow us to perform gap analysis and will also guide the extraction of the piloting recommendations.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''The Digital Services Model: A five-layered approach'''&lt;br /&gt;
&lt;br /&gt;
The LSPs so far have developed building blocks that enable cross-border interoperability based on standards, specifications and common code/components. Therefore, moving beyond the pilot projects and towards actual deployment, it is crucial to develop a structure in which the digital services and the elements they are composed of can be conceptualized.&lt;br /&gt;
&lt;br /&gt;
To establish a conceptual model, it is important to clearly set out the key terminology that is used in relation to the DSI for the provision of cross-border public services. CEF provides an overarching framework suitable for this purpose, called Digital Services Model (DSM). It takes into account the deliverables of the LSPs, the stakeholders and roles they can take on, and the drivers behind the dynamics of this complex ecosystem.&lt;br /&gt;
&lt;br /&gt;
The Digital Services Model is not only needed to establish common terminology and framework, but it is also necessary to analyse the needs and requirements for the future deployment of any digital services, enabling a continuity of the developed methodologies with the LSPs. Thus, it presents the different levels of granularity which need to be taken into consideration for the overall management of the DSI for the provision of public Services.&lt;br /&gt;
&lt;br /&gt;
The following elements represent the main part of the DSM taxonomy:&lt;br /&gt;
&lt;br /&gt;
# Standards and Specifications;&lt;br /&gt;
# Common code or Components;&lt;br /&gt;
# Building Blocks;&lt;br /&gt;
# Core Service Platforms;&lt;br /&gt;
# Generic Services.&lt;br /&gt;
&lt;br /&gt;
Standards and Specifications have been used by all the LSPs for the development of the digital services. These standards and specifications play a central role in interoperability as it means that systems have commonalities in key areas, enabling systems to communicate with one another.&lt;br /&gt;
&lt;br /&gt;
Components are the common code that has been developed for the building blocks. Building blocks are made up of several components (e.g. a timestamp component/functionality). These are often referred to as modules in the deliverables of the LSPs. Component can either be BB-specific or used in several BB.&lt;br /&gt;
&lt;br /&gt;
Essentially, all the solutions derived from the LSPs are ultimately building blocks in the sense that they are services that can be integrated as part of other services. Given the fact that these building blocks have the most obvious potential for reuse across different domains (or Core Service Platforms) these can be seen as a specific layer as part of the set of digital services.&lt;br /&gt;
&lt;br /&gt;
Core Service Platforms enable the provision of cross-border digital services in different domains, like eHealth, eJustice and eProcurement. These are the platforms where all the different BB for a specific service (e.g. eHealth services or eID services) are brought together and made available, enabling service providers to take up and reuse the services as part of their own services. The Core Service Platform (CSP) level should eventually enable the Member States to interact with other Member States through the use of building blocks (via the Generic Services).&lt;br /&gt;
&lt;br /&gt;
It is important to determine what building blocks have been developed by an LSP, as well as which of these are CSP-specific and which are reusable. The CSP-specific blocks are called domain blocks (e.g. ePrescription is specific to eHealth) and the reusable blocks are called building blocks (e.g. eID can be reused in various domains).&lt;br /&gt;
&lt;br /&gt;
The reusable building blocks are the strongest common element between the various CSPs. They therefore need to meet the needs and requirements of all the CSPs. This underlines the links between the building blocks and the CSPs, and the need to manage both of these simultaneously.&lt;br /&gt;
&lt;br /&gt;
Generic Services is the level of abstraction at which the Member States integrate or connect to the CSPs. These interconnections are necessary to link up a Member State so it can provide cross-border access and use of national eIDs, electronic health records, national procurement platforms, national eJustice platforms and public services for foreign business. Each Member State has to ensure that these existing systems at national level are linked up with the CSPs through Generic Services in order to be cross-border enabled.&lt;br /&gt;
&lt;br /&gt;
To define a common taxonomy for BB description prior to the actual assessment, the relevant BB are catalogued in view of the five-layered model described above. This is represented in the figure below (Taxonomy of Building Blocks). &lt;br /&gt;
[[File:Taxonomy of Building Blocks.png|alt=Taxonomy of Building Blocks|Taxonomy of Building Blocks|center|frame]]Although implicitly understandable, it is worth noting that some BB can belong to two different categories, as their application is largely context dependent. In other words, whereas in one context a certain BB can be seen as a Standard/Specification, in another context it can be a Component. In those cases, the more general category is assigned to that BB, giving priority to show its potential rather than its most common use. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Assessment criteria'''&lt;br /&gt;
&lt;br /&gt;
In this section, a basic assessment framework is presented composed of the criteria that guide the expert scoring of BB from the aspect of technical, administrative and operational maturity. The criteria essentially represent a matrix indexed by two dimensions: Score and Maturity aspect. These dimensions, together with the semantics of the criteria (the matrix-cells) are shown in the table below (Conceptual BB assessment framework). For better graphical representation of the empirical assessment that will be performed in the next section, each row is represented by a colour, visually grasping the overall maturity of a certain building block.&lt;br /&gt;
[[File:Conceptual BB assessment framework.png|alt=Conceptual BB assessment framework|center|thumb|600x600px|Conceptual BB assessment framework]]&lt;br /&gt;
The colouring of the framework is not important only for the visual appeal of the reader; rather, it is meant to serve as a concrete input (an additional dimension) for the prospective formalization of the assessment framework. Such formalization would enable a semi- and, ultimately, a fully automatic maturity and quality attributes assessment of both a set of desired (composable) BB, as well as a solution architecture representing a Common Service Platform or a General Service per se. &lt;br /&gt;
&lt;br /&gt;
It is important to note that the framework represented above is a simplified version of the generic assessment framework that will be the final contribution by WP2. This is because at this stage it cannot be expected that all necessary information by the pilots is obtained for an overall architecture evaluation to take place. Such assessment will be performed in the second phase of the ''BB assessment'' task, when the framework from Table 2 will also be further revised and fine-tuned. As a result, the gap analysis in the second phase will take into account the exhaustive set of pilots’ requirements and the pilots’ feedback on the implemented BB.&lt;br /&gt;
&lt;br /&gt;
=== Empirical framework ===&lt;br /&gt;
The empirical framework is essentially an implementation of the conceptual framework with concrete recommendations as an output. While the conceptual framework is based on well-standardized assessment methodologies, the (input to the) empirical evaluation of the BB relies largely on expert opinions and judgements. To close the subjectivity gap between the experts’ evaluation criteria, the BB Assessment group defined an internal process of iterative calibration on the evaluation criteria, as represented by the process flow below:&lt;br /&gt;
[[File:Calibration process for BB evaluation criteria.png|alt=Calibration process for BB evaluation criteria|center|thumb|600x600px|Calibration process for BB evaluation criteria]]&lt;br /&gt;
In the '''Preparatory step''', the building blocks were matched to the experts’ experience and expertise with respect to the capabilities provided by each BB and the architecture principles outlined by the DE4A objectives. One or more groups of BB with shared capabilities were then assigned to each expert for assessment.  &lt;br /&gt;
&lt;br /&gt;
In the '''Assessment step''', the initial evaluation criteria were agreed upon and integrated into the [https://wiki.de4a.eu/index.php/File:Conceptual_BB_assessment_framework.png basic assessment framework]. Then, the results from the initial assessments for each BB were presented in front of the BB Assessment group. This allowed for a constructive discussion on the need to fine-tune the evaluation criteria and to revise the evaluation results. These considerations are part of the '''Fine-tuning step''', which is essentially an iterative procedure on its own, until the complete set of evaluation criteria is obtained, and the BB scores are approved by all experts of the BB Assessment group.&lt;br /&gt;
&lt;br /&gt;
In the '''Recommendation step''', the final scores for each BB were provided for all three maturity aspects: Technical, Administrative and Operational. These are then analysed in view of the piloting requirements and the DE4A objectives as part of the Gap analysis, enabling the extraction of a single Recommendation as an output from the overall process.&lt;br /&gt;
&lt;br /&gt;
The output of the preparatory step is the Taxonomy of BB, whereas the output of the Assessment step is the conceptual framework – further whose criteria, aspects and semantics were fine-tuned in the third step. The scores and recommendations are obtained as an output from the final (Recommendation) step, supported by the argumentation given in the Gap Analysis. For a more complete overview of the final scores and recommendation, they are succinctly represented altogether in the BB recommendations table below. &lt;br /&gt;
&lt;br /&gt;
=== Recommendations and Gap Analysis ===&lt;br /&gt;
This section summarizes the assessment for each building block, by aspect and with an overall recommendation grade. A recommendation is essentially the expert opinion based on the results from the conceptual framework, the gap analysis and in relation to the piloting needs and requirements. The overall list of assessed BB is catalogued as follows:&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|+BB recommendations&lt;br /&gt;
|'''#'''&lt;br /&gt;
|'''Building Block'''&lt;br /&gt;
|'''Technical Maturity'''&lt;br /&gt;
|'''Administrative Maturity'''&lt;br /&gt;
|'''Operational Maturity'''&lt;br /&gt;
|'''Recommendation'''&lt;br /&gt;
|-&lt;br /&gt;
|1&lt;br /&gt;
|eDelivery&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Implemented  and running&lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Completely  aligned with current EU policies &lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | runs  in production in EU (one or more MS) &lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Recommended&lt;br /&gt;
|-&lt;br /&gt;
|2&lt;br /&gt;
|eID&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Implemented  and running&lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Completely  aligned with current EU policies &lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | runs  in production in EU (one or more MS) &lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Recommended&lt;br /&gt;
|-&lt;br /&gt;
|3&lt;br /&gt;
|eSignature&lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Cutting-edge &lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Completely  aligned with current EU policies &lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | runs  in production in EU (one or more MS) &lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Recommended&lt;br /&gt;
|-&lt;br /&gt;
|4&lt;br /&gt;
|CCCEV&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Implemented  and running&lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Completely  aligned with current EU policies &lt;br /&gt;
| style=&amp;quot;background-color:#FFFF00;&amp;quot; | Piloted &lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Acceptable&lt;br /&gt;
|-&lt;br /&gt;
|5&lt;br /&gt;
|CPSV-AP&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Implemented  and running&lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Completely  aligned with current EU policies &lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | runs  in production in EU (one or more MS) &lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Acceptable&lt;br /&gt;
|-&lt;br /&gt;
|6&lt;br /&gt;
|eCertis&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Implemented  and running&lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Completely  aligned with current EU policies &lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | EU  infrastructure, broadly accepted &lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Recommended&lt;br /&gt;
|-&lt;br /&gt;
|7&lt;br /&gt;
|eIDAS interoperability  specifications&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Implemented  and running&lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Completely  aligned with current EU policies &lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | runs  in production in EU (one or more MS) &lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Acceptable&lt;br /&gt;
|-&lt;br /&gt;
|8&lt;br /&gt;
|sTESTA&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Implemented  and running&lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Completely  aligned with current EU policies &lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | EU  infrastructure, broadly accepted &lt;br /&gt;
| style=&amp;quot;background-color:#FF0000;&amp;quot; | Discarded&lt;br /&gt;
|-&lt;br /&gt;
|9&lt;br /&gt;
|x-Road&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Implemented  and running&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Aligned  with national policies, but is yet to be aligned with the EU&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | runs  in production in EU (one or more MS) &lt;br /&gt;
| style=&amp;quot;background-color:#FFFF00;&amp;quot; | Useful&lt;br /&gt;
|-&lt;br /&gt;
|10&lt;br /&gt;
|DCAT-AP&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Implemented  and running&lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Completely  aligned with current EU policies &lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | EU  infrastructure, broadly accepted &lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Acceptable&lt;br /&gt;
|-&lt;br /&gt;
|11&lt;br /&gt;
|BREG-DCAT-AP &lt;br /&gt;
| style=&amp;quot;background-color:#FFFF00;&amp;quot; | Not  stable/ under development &lt;br /&gt;
| style=&amp;quot;background-color:#FFFF00;&amp;quot; | Acceptable,  but subject to improvement&lt;br /&gt;
| style=&amp;quot;background-color:#FFFF00;&amp;quot; | Piloted&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Acceptable&lt;br /&gt;
|-&lt;br /&gt;
|12&lt;br /&gt;
|ISA2 Multilingual Forms&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Implemented and running&lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Completely aligned with  current EU policies &lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | runs in production in EU  (one or more MS) &lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Acceptable&lt;br /&gt;
|-&lt;br /&gt;
|13&lt;br /&gt;
|EBSI (CEF Blockchain)&lt;br /&gt;
| style=&amp;quot;background-color:#FFFF00;&amp;quot; | Not  stable/ under development &lt;br /&gt;
| style=&amp;quot;background-color:#FFFF00;&amp;quot; | Acceptable,  but subject to improvement&lt;br /&gt;
| style=&amp;quot;background-color:#FFFF00;&amp;quot; | Piloted &lt;br /&gt;
| style=&amp;quot;background-color:#FFFF00;&amp;quot; | Useful&lt;br /&gt;
|-&lt;br /&gt;
|14&lt;br /&gt;
|eInvoicing&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Implemented  and running&lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Completely  aligned with current EU policies &lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | EU  infrastructure, broadly accepted &lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Recommended&lt;br /&gt;
|-&lt;br /&gt;
|15&lt;br /&gt;
|eTranslation&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Implemented  and running&lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Completely  aligned with current EU policies &lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | EU  infrastructure, broadly accepted &lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Recommended&lt;br /&gt;
|-&lt;br /&gt;
|16&lt;br /&gt;
|SEMPER&lt;br /&gt;
| style=&amp;quot;background-color:#FFFF00;&amp;quot; | Not  stable/ under development &lt;br /&gt;
| style=&amp;quot;background-color:#FFFF00;&amp;quot; | Acceptable,  but subject to improvement&lt;br /&gt;
| style=&amp;quot;background-color:#FFFF00;&amp;quot; | Piloted&lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Recommended&lt;br /&gt;
|-&lt;br /&gt;
|17&lt;br /&gt;
|BRIS&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Implemented  and running&lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Completely  aligned with current EU policies &lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | EU  infrastructure, broadly accepted &lt;br /&gt;
| style=&amp;quot;background-color:#FF0000;&amp;quot; | Discarded&lt;br /&gt;
|-&lt;br /&gt;
|18&lt;br /&gt;
|TOOP Architecture&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Implemented and running&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Aligned with national  policies, but is yet to be aligned with the EU&lt;br /&gt;
| style=&amp;quot;background-color:#FFFF00;&amp;quot; | Piloted &lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Recommended&lt;br /&gt;
|-&lt;br /&gt;
|19&lt;br /&gt;
|TOOP CERB&lt;br /&gt;
| style=&amp;quot;background-color:#FFFF00;&amp;quot; | Not stable/ under  development &lt;br /&gt;
| style=&amp;quot;background-color:#FFFF00;&amp;quot; | Acceptable, but subject  to improvement&lt;br /&gt;
| style=&amp;quot;background-color:#FFFF00;&amp;quot; | Piloted &lt;br /&gt;
| style=&amp;quot;background-color:#FFFF00;&amp;quot; | Useful&lt;br /&gt;
|-&lt;br /&gt;
|20&lt;br /&gt;
|TOOP DSD&lt;br /&gt;
| style=&amp;quot;background-color:#FFFF00;&amp;quot; | Not stable/ under  development &lt;br /&gt;
| style=&amp;quot;background-color:#FFFF00;&amp;quot; | Acceptable, but subject  to improvement&lt;br /&gt;
| style=&amp;quot;background-color:#FFFF00;&amp;quot; | Piloted &lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Acceptable &lt;br /&gt;
|-&lt;br /&gt;
|21&lt;br /&gt;
|TOOP eDelivery [SMP/SML and BDXL]&lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Cutting-edge &lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Aligned with national  policies, but is yet to be aligned with the EU&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | runs in production in EU  (one or more MS) &lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Recommended&lt;br /&gt;
|-&lt;br /&gt;
|22&lt;br /&gt;
|TOOP EDM&lt;br /&gt;
| style=&amp;quot;background-color:#FFFF00;&amp;quot; | Not stable/ under development &lt;br /&gt;
| style=&amp;quot;background-color:#FFFF00;&amp;quot; | Acceptable, but subject  to improvement&lt;br /&gt;
| style=&amp;quot;background-color:#FF0000;&amp;quot; | Concept &lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Acceptable&lt;br /&gt;
|-&lt;br /&gt;
|23&lt;br /&gt;
|TOOP TC&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Implemented and running&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Aligned with national  policies, but is yet to be aligned with the EU&lt;br /&gt;
| style=&amp;quot;background-color:#FFFF00;&amp;quot; | Piloted &lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Recommended&lt;br /&gt;
|-&lt;br /&gt;
|24&lt;br /&gt;
|TOOP Gateway&lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Cutting-edge &lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Aligned with national  policies, but is yet to be aligned with the EU&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | runs in production in EU  (one or more MS) &lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Recommended&lt;br /&gt;
|-&lt;br /&gt;
|25&lt;br /&gt;
|TOOP Testing Tool&lt;br /&gt;
| style=&amp;quot;background-color:#FFFF00;&amp;quot; | Not stable/ under  development &lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Acceptable, but subject  to improvement&lt;br /&gt;
| style=&amp;quot;background-color:#FFFF00;&amp;quot; | Piloted &lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Acceptable&lt;br /&gt;
|-&lt;br /&gt;
|26&lt;br /&gt;
|ADMS-AP&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Implemented  and running&lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Completely  aligned with current EU policies &lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | EU  infrastructure, broadly accepted &lt;br /&gt;
| style=&amp;quot;background-color:#FFFF00;&amp;quot; | Useful&lt;br /&gt;
|-&lt;br /&gt;
|27&lt;br /&gt;
|EDCI&lt;br /&gt;
| style=&amp;quot;background-color:#FFFF00;&amp;quot; | Not  stable/ under development &lt;br /&gt;
| style=&amp;quot;background-color:#FFFF00;&amp;quot; | Acceptable,  but subject to improvement&lt;br /&gt;
| style=&amp;quot;background-color:#FFFF00;&amp;quot; | Piloted&lt;br /&gt;
| style=&amp;quot;background-color:#FFFF00;&amp;quot; | Useful&lt;br /&gt;
|-&lt;br /&gt;
|28&lt;br /&gt;
|EES&lt;br /&gt;
| style=&amp;quot;background-color:#FFFF00;&amp;quot; | Not  stable/ under development &lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Aligned  with national policies, yet to be aligned with the EU&lt;br /&gt;
| style=&amp;quot;background-color:#FF0000;&amp;quot; | Concept&lt;br /&gt;
| style=&amp;quot;background-color:#FFFF00;&amp;quot; | Useful&lt;br /&gt;
|-&lt;br /&gt;
|29&lt;br /&gt;
|eTimeStamp&lt;br /&gt;
| style=&amp;quot;background-color:#FFFF00;&amp;quot; | Not  stable/ under development &lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Completely  aligned with current EU policies &lt;br /&gt;
| style=&amp;quot;background-color:#FF0000;&amp;quot; | Concept&lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Recommended&lt;br /&gt;
|-&lt;br /&gt;
|30&lt;br /&gt;
|eDocument&lt;br /&gt;
| style=&amp;quot;background-color:#FFFF00;&amp;quot; | Not  stable/ under development &lt;br /&gt;
| style=&amp;quot;background-color:#FFFF00;&amp;quot; | Acceptable,  but subject to improvement&lt;br /&gt;
| style=&amp;quot;background-color:#FF0000;&amp;quot; | Concept &lt;br /&gt;
| style=&amp;quot;background-color:#FF0000;&amp;quot; | Discarded&lt;br /&gt;
|-&lt;br /&gt;
|31&lt;br /&gt;
|RPAM&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Implemented  and running&lt;br /&gt;
| style=&amp;quot;background-color:#FFFF00;&amp;quot; | Acceptable,  but subject to improvement&lt;br /&gt;
| style=&amp;quot;background-color:#FFFF00;&amp;quot; | Piloted &lt;br /&gt;
| style=&amp;quot;background-color:#FFFF00;&amp;quot; | Useful&lt;br /&gt;
|-&lt;br /&gt;
|32&lt;br /&gt;
|SMP/SML&lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Cutting-edge &lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Completely  aligned with current EU policies &lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | runs in production in EU  (one or more MS) &lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Recommended&lt;br /&gt;
|-&lt;br /&gt;
|33&lt;br /&gt;
|IMI&lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Cutting-edge &lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Completely  aligned with current EU policies &lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | EU  infrastructure, broadly accepted &lt;br /&gt;
| style=&amp;quot;background-color:#FF0000;&amp;quot; | Discarded&lt;br /&gt;
|}&lt;br /&gt;
Following is the analysis of the results from the overall assessment from the aspect of the pilots’ needs, the conceptual framework and the overall architectural principles. It is important to note that this is not the exhaustive set of gap analysis, but it serves as a proof of concept for the methodological and assessment choices decisions made. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Pilots needs’ considerations'''&lt;br /&gt;
&lt;br /&gt;
From the table above, it can be noted that, although some of the BB are assessed as immature from some aspect, the final recommendation is still for them to be used by the pilots. This is due to the fact that, regardless of the current state of maturity, when matched with the pilots’ requirements, some a BB may still have the necessary architecture capabilities that require adjustment in the DE4A context. For instance, this is the case with SEMPER. The SEMPER extension to eIDAS is not fully mature yet but is the only cross-border functionality for working with proxies that currently mandates successfully piloted. Otherwise, there will be a need to develop a DE4A-specific solution for cross-border powers validation from the scratch, which is bot not useful and not feasible within the project timeframe. In order for SEMPER to gain a broader user-base, it has to be validated by more Member States (currently, it has been piloted with 4 MS). In addition, SEMPER has been piloted with legal persons only. Although this is sufficient to the DBA pilot, this is not the case for the moving abroad and studying abroad, as there is a need for piloting with natural persons. The DE4A pilots themselves may be used for this. Finally, SEMPER extends eIDAS, but has not been handed over to DIGIT yet. Therefore, it has not been incorporated in the eIDAS reference software of DIGIT yet. Integration in eIDAS will improve sustainability of the SEMPER extension. Concretely, SEMPER would benefit from eIDAS-like specifications to allow Member States that do not use the eIDAS reference software to develop their own extension based on these specifications. &lt;br /&gt;
&lt;br /&gt;
In contrast to SEMPER, there is also a case where a BB may be assessed as completely mature in most of the aspects but is still disregarded at the Recommendations stage. This is, for instance, the case with the IMI BB, which despite the overall high maturity in all aspects is out of the scope of the DE4A project. Similarly, the BRIS building block has a scope that is much narrower (especially from an administrative perspective) than the scope of DE4A and is therefore not to be used by the pilots. More concretely, BRIS has been developed for inter-business register communication, which is not the primary focus of the DBA pilot (the functional shortcomings on BRIS for piloting in DBA (D4.5, annex V) have been confirmed by DG DIGIT and there is no BRIS-roadmap foreseen that will deliver a solution to the findings). Furthermore, it is legally not feasible to use the BRIS-network for the DE4A-pilots (currently not allowed for non-business registers). An alternative is being discussed with DIGIT: a message broking platform as a possible future BRIS-wide solution that is piloted in TOOP. However, funding for continuation of the platform is not arranged and the current intention is to bring the (cloud-based) prototype infrastructure down when TOOP testing ends.&lt;br /&gt;
&lt;br /&gt;
Similar reasoning in compiling the overall recommendation score is applied to the other building blocks. These considerations have been discussed in detail at the BB Assessment Group meetings during the Recommendation step of the empirical framework. It is out of scope of the deliverable to present a detailed overview of each BB. However, the subtlety of some of the assessment criteria (such as context dependence) is also an argument to justify the decision to rely only on the experts’ evaluations in the first phase of the methodology.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Assessment outcomes considerations'''&lt;br /&gt;
&lt;br /&gt;
Out of the 33 assessed BB, 13 BB are Recommended for implementation, 9 are Acceptable, 7 are Useful and 4 are Discarded. From a maturity point of view: in terms of technical maturity, 5 are cutting-edge, 18 are implemented and running in an operational environment, whereas 10 are not stable or under development. From an administrative maturity aspect, almost half (17) of the BB are completely aligned with current EU policies; 7 are aligned with national policies but are yet to be consolidated at an EU level, whereas 9 (although acceptable) are still subject to further improvements. &lt;br /&gt;
[[File:Taxonomy of assessed BB with their recommendations .png|alt=Taxonomy of assessed BBs with their recommendations |center|frame|Taxonomy of assessed BB with their recommendations ]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
From operational maturity aspect, there are 8 BB which are broadly accepted as part of an EU infrastructure, 12 that run in production in one or more Member States and 10 that are piloted within some kind of operational or testing environment. It is interesting to note that the only aspect by which a BB has been assessed as immature is the Operational aspect. Thus, there are 4 BB (TOOD EDM, EES, eTimeStamp and eDocument) that are marked as operationally immature, as they are only at the stage of a Concept and are yet to be developed.&lt;br /&gt;
&lt;br /&gt;
From a BB type aspect (also visible in the figure above), most of the recommended BB are of the type ‘Building Block’ (7 out of 13) and ‘Standards and specifications’, whereas the ‘General services’ and the ‘Core service platforms’ are the least numerous and the most immature. This is expected, as the later are also the most complex ones and only few in number across EU. &lt;br /&gt;
&lt;br /&gt;
It is also notable that most of the BB considered for use by the pilots are in a mature and useful state that allows reusability and potential upgrades before implementation in the DE4A pilots. Such considerations are already being made (as discussed in the previous subsection) and are part of the piloting requirements to be assessed in the second phase of the methodology. &lt;br /&gt;
&lt;br /&gt;
'''Architecture framework considerations'''&lt;br /&gt;
&lt;br /&gt;
As outlined in the methodological considerations above, the two phases of the overall methodology follow the Enterprise Architecture Assessment Framework principles, with the additional step of providing recommendations for the pilot in between the two phases. Such an approach allows, in addition to the qualitative evaluation, to obtain e quantitative score for the maturity of the overall architecture as a (sub)set of the assessed BB. In that sense, while the output of the EAAF is a maturity level assessment of the overall architecture, the phased approach in DE4A creates an intermediate feedback loop between the pilots and the Project Start Architecture, allowing for adaptable integration of the assessment methodology within the WP2 change management.&lt;br /&gt;
&lt;br /&gt;
Regardless of the incomplete overall assessment, it is still possible to have a quantitative assessment for a solution architecture after the first assessment phase. However, this is not to be considered as the overall architecture framework maturity level, but only as a ‘current maturity level’ of the solution architecture comprised of a given set of BB. Such value can serve as a reference point to be compared upon a given KPI for the overall maturity, in case there is such requirement.&lt;br /&gt;
&lt;br /&gt;
In order to compile a single value for the current maturity level for a pilot solution architecture, the set of BB assessments and their recommendations shall be compared upon the baseline for the EAAF maturity levels.&lt;br /&gt;
[[File:EAAF Maturity levels.png|alt=EAAF Maturity levels|center|frame|EAAF Maturity levels]]&lt;br /&gt;
In the context of DE4A, we will provide such assessment in the second phase of implementation of this methodology, as currently there is no definite list of BB matched to the specific pilots.&lt;/div&gt;</summary>
		<author><name>Ictu mavi.cristache</name></author>
	</entry>
	<entry>
		<id>https://wiki.de4a.eu/index.php?title=Building_Blocks&amp;diff=3004</id>
		<title>Building Blocks</title>
		<link rel="alternate" type="text/html" href="https://wiki.de4a.eu/index.php?title=Building_Blocks&amp;diff=3004"/>
		<updated>2021-07-15T16:39:20Z</updated>

		<summary type="html">&lt;p&gt;Ictu mavi.cristache: /* Recommendations and Gap Analysis */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The purpose of the Building Blocks (BB) assessment is to assess the suitability of the BB identified and catalogued in Task 1.5 for use within the DE4A project. Thus, it bridges outputs from WP1 and requirements from WP4 to provide input for the technical, operational and administrative considerations in the architectural assessments carried out here. Over 40 BB have been considered for this assessment, 31 of which are assessed at the first phase of this work. The results of the assessment show that there is a mature and acceptable stock of solution building blocks that can be considered as potential candidates for implementation by the pilots, either in their entirety or partially, with the needed upgrades.&lt;br /&gt;
&lt;br /&gt;
== Theoretical background ==&lt;br /&gt;
&lt;br /&gt;
=== Objectives and scope ===&lt;br /&gt;
To reach the goal outlined above, this section delves into the architectural evaluation of the building blocks catalogued as useful for DE4A. It is important to note that the term “building block” in the context of this assessment refers to a Solution Building Block in TOGAF sense. &lt;br /&gt;
&lt;br /&gt;
The most important step in assessing the BB is determining the methodology that would support a common description framework of the BB, while providing means for determining the quantitative and/or qualitative evaluation criteria of the considered BB. The outcome of the assessment is a succinct list of recommendations for BB use by the pilots in WP4. In addition to defining the methodology, a gap analysis is performed based on both the pilots’ requirements and the common description framework of the BB, considering the results from the assessment, the project requirements and the common PSA principles. The overall process of conceptual considerations, empirical evaluation, gap analysis and piloting recommendations are denoted as a DE4A generic methodology for architecture building blocks evaluation.&lt;br /&gt;
&lt;br /&gt;
=== Available methodologies ===&lt;br /&gt;
In order to provide continuity and justification of the methodology that is being developed, we first outline and assess the suitability of the currently available methodologies in view of the implementation context and the objectives of the DE4A project. To that end, both generic EU/EC assessment methodologies and past LSP project-specific methodologies are considered.&lt;br /&gt;
&lt;br /&gt;
==== Common assessment method for standards and specifications (CAMSS) ====&lt;br /&gt;
[https://ec.europa.eu/isa2/solutions/camss_en CAMSS] is part of the ISA² interoperability solutions evaluation toolkit for public administrations, businesses and citizens. It provides a method to assist in the assessment of ICT standards and specifications. The main objective of CAMSS is achieving interoperability and avoiding vendor lock-in. In that sense, CAMSS criteria evaluate (among other things) the openness of standards and specifications. This is done by employing the CAMSS tools and adapting the evaluation according to the needs of an individual Member State.&lt;br /&gt;
&lt;br /&gt;
In the context of DE4A, relying solely on CAMSS does not provide the means for BB suitability and gap analysis in relation to the piloting needs. Moreover, it does not provide any selection criteria or a taxonomy for consistent mapping of the different BB onto a common comparable framework.&lt;br /&gt;
&lt;br /&gt;
==== Past project-specific methodologies ====&lt;br /&gt;
'''eSENS'''&lt;br /&gt;
&lt;br /&gt;
eSENS has developed its own methodology for BB assessment, which is mainly an adaptation of CAMSS and Asset Description Metadata Schema (ADMS), supported by inputs of the [https://web.archive.org/web/20200928232327/http://www.esens.eu/deliverables eSENS deliverable D6.1] (see Table 5 in [https://web.archive.org/web/20200928232327/http://www.esens.eu/deliverables eSENS D3.1]). Its objective is to propose a documentation of format and defining criteria for the maturity and sustainability assessment of building blocks. The overall framework consists of three steps: 1) The Consideration step; 2) The Assessment step; and 3) The Recommendation step and produces a list of assessment criteria to be used for BB evaluation. These criteria, however, are very general and not architecture-specific – their applicability is valid and valuable only if used in collaboration with the legal, business, organizational, technical and implementation team.&lt;br /&gt;
&lt;br /&gt;
It is important to note that the assessment methodology employed in eSENS is developed with a different aim from ours – its analysis and recommendations refer to the desired BB qualities that are needed to ensure meeting the maturity levels and the sustainability criteria envisaged by the project. Thus, although it produces guidelines for assessment, it does not provide concrete output in terms of actual scores, analysis and recommendations for BB. Moreover, it does not provide a comparable baseline when multiple BB have to be considered for the same pilot and it is based on the assumption that the existing BB represent the exhaustive list of possible solutions from which a suitable match should be chosen. In the case of DE4A, such an assumption does not hold, as there may be a case where a certain BB is not mature enough to be recommended for piloting but is also not to be completely disregarded either. More importantly, the methodology developed here is used for actual assessment and is to be fine-tuned at a later stage in connection to the general architecture lifecycle development.&lt;br /&gt;
&lt;br /&gt;
'''TOOP'''&lt;br /&gt;
&lt;br /&gt;
Like eSENS, the overall idea of the TOOP assessment methodology is to reuse existing frameworks and building blocks provided by CEF, eSENS, and other initiatives. First, an initial inventory of existing e- Government building blocks is proposed. Then, the principles of selection of building blocks for OOP applications are provided, together with high-level views of the architecture. Finally, an analysis of selected building blocks is done with respect to their relevance, applicability, sustainability, need for further development and external interfaces.&lt;br /&gt;
&lt;br /&gt;
The main criteria for inclusion of a building block in TOOP are:&lt;br /&gt;
&lt;br /&gt;
* The specific project requirements;&lt;br /&gt;
* The TOOP pilots’ needs;&lt;br /&gt;
* Usability in long-term applications (maintenance and support provided).&lt;br /&gt;
&lt;br /&gt;
As a result, the building blocks are categorized into three basic groups:&lt;br /&gt;
&lt;br /&gt;
# BB that provide capabilities needed by all or most TOOP Pilot Areas;&lt;br /&gt;
# BB that provide capabilities needed or probably needed by some TOOP Pilot Areas;&lt;br /&gt;
# BB that provide capabilities not needed by the TOOP Pilot Areas.&lt;br /&gt;
&lt;br /&gt;
TOOP’s criteria are tightly bound to the piloting needs, whereas the rationale behind their choice is OOP-specific rather than generic. The methodology here follows a similar line of reasoning, but differs in the conceptual framework, which is more formally defined and made reusable by other projects as well. &lt;br /&gt;
&lt;br /&gt;
==== ISA2 Interim Evaluation ====&lt;br /&gt;
The [https://ec.europa.eu/isa2/sites/isa/files/190613_synopsis_report.pdf interim evaluation] aimed to assess how well the ISA² Programme has performed since its start in 2016 and whether its existence continues to be justified. Based on stakeholders’ views, opinions and public consultation, it evaluated the implementation of the programme based on seven criteria and identified several points for improvement. &lt;br /&gt;
&lt;br /&gt;
The evaluation criteria considered were: Relevance (the alignment between the objectives of the programme and the current needs and problems experienced by stakeholders); Effectiveness (the extent to which the programme has achieved its objectives); Efficiency (the extent to which the programme’s objectives are achieved at a minimum cost); Coherence (the alignment between the programme and comparable EU initiatives as well as the overall EU policy framework); EU added value (the additional impacts generated by the programme, as opposed to leaving the subject matter in the hands of Member States); Utility (the extent to which the programme meets stakeholders’ needs); and Sustainability (the likelihood that the programme’s results will last beyond its completion).&lt;br /&gt;
&lt;br /&gt;
However, the interim evaluation does not provide a specific methodology – either in terms of criteria choice, or in terms of architectural or future piloting recommendations. Its value lies mainly in the identification of possible gaps that exist within the current EU architecture framework even prior to the implementation of the available building blocks. In that sense, the main recommendations for prospective actions are determined in awareness raising beyond national administrations; moving from user-centric to user-driven solutions; and working towards increased sustainability.&lt;br /&gt;
&lt;br /&gt;
Our work integrates the interim evaluation criteria even at the stage of cataloguing BB relevant in DE4A context. More importantly, it takes into consideration the methodological gaps identified in the assessment in terms of awareness, user-driven solutions and sustainability prescriptions and integrates specific technical, administrative and operational aspects in the recommendation’s extraction for the pilots. &lt;br /&gt;
&lt;br /&gt;
==== EAAF ====&lt;br /&gt;
The [https://obamawhitehouse.archives.gov/sites/default/files/omb/assets/fea_docs/OMB_EA_Assessment_Framework_v3_1_June_2009.pdf Enterprise Architecture Assessment Framework (EAAF)] assists the US government in the assessment and reporting of their enterprise architecture activity and maturity, as well as in the advancement of the use of enterprise architecture to guide political decisions on IT investments. In addition to providing the methods for the assessment, EAAF also identifies the measurement areas and criteria by which government agencies are to rely on the architecture to drive performance improvements. This is integrated into the so-called Performance Improvement Lifecycle, where points for improvement are identified and translated into specific actions.&lt;br /&gt;
&lt;br /&gt;
In that sense, the framework provides a good overall methodology for the assessment of DE4A BB. Following its guidelines, in order to perform the technical assessment, the architects, together with the relevant project partners (mainly from WP1 and WP4):&lt;br /&gt;
&lt;br /&gt;
* Identify and prioritize the BB considering the pilots’ needs and in view of the project goals and objectives;&lt;br /&gt;
* Determine specific methodological steps for gap analysis, using common or shared information assets and information technology assets;&lt;br /&gt;
* Quantify/qualify and assess the performance to verify compliance with pilots’ requirements and provide report on gap closure; and&lt;br /&gt;
* Assess feedback on the pilots’ performance in order to enhance the architecture and fine-tune the assessment methodology for future implementation decisions.&lt;br /&gt;
&lt;br /&gt;
=== Methodological considerations ===&lt;br /&gt;
The need to develop a generic methodology that integrates some aspects of the standardized methodologies, but does not rely on a single one, is based on several considerations: &lt;br /&gt;
&lt;br /&gt;
# The assessment methodologies currently available either focus on alignment of the BB specifications or are only concerned with the maturity of the solution provided by the building blocks; &lt;br /&gt;
# They do not provide a clear definition of the common principles for assessment;&lt;br /&gt;
# They do not allow for a phased-approach to the assessment and are applicable either for a single BB or for a finalized solution architecture (Note: Although EAAF prescribes the principles for a phased assessment, it does not delineate the phases explicitly and only gives a requirement for the overall outcome of the assessment). &lt;br /&gt;
&lt;br /&gt;
As a result, the architect is prevented from developing an assessment for multiple BB with varying levels of complexity and is also disabled to perform comparative evaluation for determining the best fit for a particular solution architecture. &lt;br /&gt;
&lt;br /&gt;
The methodology developed here is novel in that it addresses the points above and is also generic in the sense that it can be reused by other large-scale projects for similar purposes. It incorporates the assessment principles of existing standards-based methodologies (like CAMSS and EAAF) taking into account the architecture feasibility and sustainability, but it also generalizes these principles over the context of implementation required by DE4A.&lt;br /&gt;
&lt;br /&gt;
== Methodology ==&lt;br /&gt;
In order to account for both the piloting recommendations criteria and the performance assessment criteria, the overall methodology requires a phased approach. Therefore, it consists of two phases:&lt;br /&gt;
&lt;br /&gt;
I) The first phase takes stock of the entire list of BB that can have potential use in the project and as part of the piloting. Then, a conceptual and an empirical framework for evaluation is developed – the former enables the gap analysis of the BB, whereas the latter allows for qualitative and comparative analysis of the BB, as well as extraction of concrete recommendations for piloting. The first phase essentially corresponds to the first three points of the EAAF.&lt;br /&gt;
&lt;br /&gt;
II) The second phase will account for the complete list of project artefacts and will provide empirical validation for the results and recommendations from the first phase. In addition, reassessment of the previous gaps will be performed. This phase will mainly be realized in close collaboration with the pilots: direct feedback via surveys and questionnaires on BB performance will be obtained and the initial conceptual framework will be fine-tuned accordingly. The second phase corresponds to the last point of the EAAF.&lt;br /&gt;
&lt;br /&gt;
=== Conceptual framework ===&lt;br /&gt;
In this section, we first catalogue the BB that are to be considered by the assessment. This step considers the output from D1.5 and establishes a relation to the internal project environment. Then we establish a common conceptualization of the key elements, which is based on the Digital service model, Section 2.2 of the Study on &amp;quot;The feasibility and scenarios for the long-term sustainability of the Large Scale Pilots”. With that, a relation to the external project environment is established. Finally, a basic assessment framework is developed to enable the grading of the BB from several maturity aspects: technical, administrative and operational. The output of the assessment will allow us to perform gap analysis and will also guide the extraction of the piloting recommendations.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''The Digital Services Model: A five-layered approach'''&lt;br /&gt;
&lt;br /&gt;
The LSPs so far have developed building blocks that enable cross-border interoperability based on standards, specifications and common code/components. Therefore, moving beyond the pilot projects and towards actual deployment, it is crucial to develop a structure in which the digital services and the elements they are composed of can be conceptualized.&lt;br /&gt;
&lt;br /&gt;
To establish a conceptual model, it is important to clearly set out the key terminology that is used in relation to the DSI for the provision of cross-border public services. CEF provides an overarching framework suitable for this purpose, called Digital Services Model (DSM). It takes into account the deliverables of the LSPs, the stakeholders and roles they can take on, and the drivers behind the dynamics of this complex ecosystem.&lt;br /&gt;
&lt;br /&gt;
The Digital Services Model is not only needed to establish common terminology and framework, but it is also necessary to analyse the needs and requirements for the future deployment of any digital services, enabling a continuity of the developed methodologies with the LSPs. Thus, it presents the different levels of granularity which need to be taken into consideration for the overall management of the DSI for the provision of public Services.&lt;br /&gt;
&lt;br /&gt;
The following elements represent the main part of the DSM taxonomy:&lt;br /&gt;
&lt;br /&gt;
# Standards and Specifications;&lt;br /&gt;
# Common code or Components;&lt;br /&gt;
# Building Blocks;&lt;br /&gt;
# Core Service Platforms;&lt;br /&gt;
# Generic Services.&lt;br /&gt;
&lt;br /&gt;
Standards and Specifications have been used by all the LSPs for the development of the digital services. These standards and specifications play a central role in interoperability as it means that systems have commonalities in key areas, enabling systems to communicate with one another.&lt;br /&gt;
&lt;br /&gt;
Components are the common code that has been developed for the building blocks. Building blocks are made up of several components (e.g. a timestamp component/functionality). These are often referred to as modules in the deliverables of the LSPs. Component can either be BB-specific or used in several BB.&lt;br /&gt;
&lt;br /&gt;
Essentially, all the solutions derived from the LSPs are ultimately building blocks in the sense that they are services that can be integrated as part of other services. Given the fact that these building blocks have the most obvious potential for reuse across different domains (or Core Service Platforms) these can be seen as a specific layer as part of the set of digital services.&lt;br /&gt;
&lt;br /&gt;
Core Service Platforms enable the provision of cross-border digital services in different domains, like eHealth, eJustice and eProcurement. These are the platforms where all the different BB for a specific service (e.g. eHealth services or eID services) are brought together and made available, enabling service providers to take up and reuse the services as part of their own services. The Core Service Platform (CSP) level should eventually enable the Member States to interact with other Member States through the use of building blocks (via the Generic Services).&lt;br /&gt;
&lt;br /&gt;
It is important to determine what building blocks have been developed by an LSP, as well as which of these are CSP-specific and which are reusable. The CSP-specific blocks are called domain blocks (e.g. ePrescription is specific to eHealth) and the reusable blocks are called building blocks (e.g. eID can be reused in various domains).&lt;br /&gt;
&lt;br /&gt;
The reusable building blocks are the strongest common element between the various CSPs. They therefore need to meet the needs and requirements of all the CSPs. This underlines the links between the building blocks and the CSPs, and the need to manage both of these simultaneously.&lt;br /&gt;
&lt;br /&gt;
Generic Services is the level of abstraction at which the Member States integrate or connect to the CSPs. These interconnections are necessary to link up a Member State so it can provide cross-border access and use of national eIDs, electronic health records, national procurement platforms, national eJustice platforms and public services for foreign business. Each Member State has to ensure that these existing systems at national level are linked up with the CSPs through Generic Services in order to be cross-border enabled.&lt;br /&gt;
&lt;br /&gt;
To define a common taxonomy for BB description prior to the actual assessment, the relevant BB are catalogued in view of the five-layered model described above. This is represented in the figure below (Taxonomy of Building Blocks). &lt;br /&gt;
[[File:Taxonomy of Building Blocks.png|alt=Taxonomy of Building Blocks|Taxonomy of Building Blocks|center|frame]]Although implicitly understandable, it is worth noting that some BB can belong to two different categories, as their application is largely context dependent. In other words, whereas in one context a certain BB can be seen as a Standard/Specification, in another context it can be a Component. In those cases, the more general category is assigned to that BB, giving priority to show its potential rather than its most common use. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Assessment criteria'''&lt;br /&gt;
&lt;br /&gt;
In this section, a basic assessment framework is presented composed of the criteria that guide the expert scoring of BB from the aspect of technical, administrative and operational maturity. The criteria essentially represent a matrix indexed by two dimensions: Score and Maturity aspect. These dimensions, together with the semantics of the criteria (the matrix-cells) are shown in the table below (Conceptual BB assessment framework). For better graphical representation of the empirical assessment that will be performed in the next section, each row is represented by a colour, visually grasping the overall maturity of a certain building block.&lt;br /&gt;
[[File:Conceptual BB assessment framework.png|alt=Conceptual BB assessment framework|center|thumb|600x600px|Conceptual BB assessment framework]]&lt;br /&gt;
The colouring of the framework is not important only for the visual appeal of the reader; rather, it is meant to serve as a concrete input (an additional dimension) for the prospective formalization of the assessment framework. Such formalization would enable a semi- and, ultimately, a fully automatic maturity and quality attributes assessment of both a set of desired (composable) BB, as well as a solution architecture representing a Common Service Platform or a General Service per se. &lt;br /&gt;
&lt;br /&gt;
It is important to note that the framework represented above is a simplified version of the generic assessment framework that will be the final contribution by WP2. This is because at this stage it cannot be expected that all necessary information by the pilots is obtained for an overall architecture evaluation to take place. Such assessment will be performed in the second phase of the ''BB assessment'' task, when the framework from Table 2 will also be further revised and fine-tuned. As a result, the gap analysis in the second phase will take into account the exhaustive set of pilots’ requirements and the pilots’ feedback on the implemented BB.&lt;br /&gt;
&lt;br /&gt;
=== Empirical framework ===&lt;br /&gt;
The empirical framework is essentially an implementation of the conceptual framework with concrete recommendations as an output. While the conceptual framework is based on well-standardized assessment methodologies, the (input to the) empirical evaluation of the BB relies largely on expert opinions and judgements. To close the subjectivity gap between the experts’ evaluation criteria, the BB Assessment group defined an internal process of iterative calibration on the evaluation criteria, as represented by the process flow below:&lt;br /&gt;
[[File:Calibration process for BB evaluation criteria.png|alt=Calibration process for BB evaluation criteria|center|thumb|600x600px|Calibration process for BB evaluation criteria]]&lt;br /&gt;
In the '''Preparatory step''', the building blocks were matched to the experts’ experience and expertise with respect to the capabilities provided by each BB and the architecture principles outlined by the DE4A objectives. One or more groups of BB with shared capabilities were then assigned to each expert for assessment.  &lt;br /&gt;
&lt;br /&gt;
In the '''Assessment step''', the initial evaluation criteria were agreed upon and integrated into the [https://wiki.de4a.eu/index.php/File:Conceptual_BB_assessment_framework.png basic assessment framework]. Then, the results from the initial assessments for each BB were presented in front of the BB Assessment group. This allowed for a constructive discussion on the need to fine-tune the evaluation criteria and to revise the evaluation results. These considerations are part of the '''Fine-tuning step''', which is essentially an iterative procedure on its own, until the complete set of evaluation criteria is obtained, and the BB scores are approved by all experts of the BB Assessment group.&lt;br /&gt;
&lt;br /&gt;
In the '''Recommendation step''', the final scores for each BB were provided for all three maturity aspects: Technical, Administrative and Operational. These are then analysed in view of the piloting requirements and the DE4A objectives as part of the Gap analysis, enabling the extraction of a single Recommendation as an output from the overall process.&lt;br /&gt;
&lt;br /&gt;
The output of the preparatory step is the Taxonomy of BB, whereas the output of the Assessment step is the conceptual framework – further whose criteria, aspects and semantics were fine-tuned in the third step. The scores and recommendations are obtained as an output from the final (Recommendation) step, supported by the argumentation given in the Gap Analysis. For a more complete overview of the final scores and recommendation, they are succinctly represented altogether in the BB recommendations table below. &lt;br /&gt;
&lt;br /&gt;
=== Recommendations and Gap Analysis ===&lt;br /&gt;
This section summarizes the assessment for each building block, by aspect and with an overall recommendation grade. A recommendation is essentially the expert opinion based on the results from the conceptual framework, the gap analysis and in relation to the piloting needs and requirements. The overall list of assessed BB is catalogued as follows:&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|+BB recommendations&lt;br /&gt;
|'''#'''&lt;br /&gt;
|'''Building Block'''&lt;br /&gt;
|'''Technical Maturity'''&lt;br /&gt;
|'''Administrative Maturity'''&lt;br /&gt;
|'''Operational Maturity'''&lt;br /&gt;
|'''Recommendation'''&lt;br /&gt;
|-&lt;br /&gt;
|1&lt;br /&gt;
|eDelivery&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Implemented  and running&lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Completely  aligned with current EU policies &lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | runs  in production in EU (one or more MS) &lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Recommended&lt;br /&gt;
|-&lt;br /&gt;
|2&lt;br /&gt;
|eID&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Implemented  and running&lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Completely  aligned with current EU policies &lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | runs  in production in EU (one or more MS) &lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Recommended&lt;br /&gt;
|-&lt;br /&gt;
|3&lt;br /&gt;
|eSignature&lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Cutting-edge &lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Completely  aligned with current EU policies &lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | runs  in production in EU (one or more MS) &lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Recommended&lt;br /&gt;
|-&lt;br /&gt;
|4&lt;br /&gt;
|CCCEV&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Implemented  and running&lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Completely  aligned with current EU policies &lt;br /&gt;
| style=&amp;quot;background-color:#FFFF00;&amp;quot; Piloted &lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Acceptable&lt;br /&gt;
|-&lt;br /&gt;
|5&lt;br /&gt;
|CPSV-AP&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Implemented  and running&lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Completely  aligned with current EU policies &lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | runs  in production in EU (one or more MS) &lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Acceptable&lt;br /&gt;
|-&lt;br /&gt;
|6&lt;br /&gt;
|eCertis&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Implemented  and running&lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Completely  aligned with current EU policies &lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | EU  infrastructure, broadly accepted &lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Recommended&lt;br /&gt;
|-&lt;br /&gt;
|7&lt;br /&gt;
|eIDAS interoperability  specifications&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Implemented  and running&lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Completely  aligned with current EU policies &lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | runs  in production in EU (one or more MS) &lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Acceptable&lt;br /&gt;
|-&lt;br /&gt;
|8&lt;br /&gt;
|sTESTA&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Implemented  and running&lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Completely  aligned with current EU policies &lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | EU  infrastructure, broadly accepted &lt;br /&gt;
| style=&amp;quot;background-color:#FF0000;&amp;quot; | Discarded&lt;br /&gt;
|-&lt;br /&gt;
|9&lt;br /&gt;
|x-Road&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Implemented  and running&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Aligned  with national policies, but is yet to be aligned with the EU&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | runs  in production in EU (one or more MS) &lt;br /&gt;
| style=&amp;quot;background-color:#FFFF00;&amp;quot; Useful&lt;br /&gt;
|-&lt;br /&gt;
|10&lt;br /&gt;
|DCAT-AP&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Implemented  and running&lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Completely  aligned with current EU policies &lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | EU  infrastructure, broadly accepted &lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Acceptable&lt;br /&gt;
|-&lt;br /&gt;
|11&lt;br /&gt;
|BREG-DCAT-AP &lt;br /&gt;
| style=&amp;quot;background-color:#FFFF00;&amp;quot; Not  stable/ under development &lt;br /&gt;
| style=&amp;quot;background-color:#FFFF00;&amp;quot; Acceptable,  but subject to improvement&lt;br /&gt;
| style=&amp;quot;background-color:#FFFF00;&amp;quot; Piloted&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Acceptable&lt;br /&gt;
|-&lt;br /&gt;
|12&lt;br /&gt;
|ISA2 Multilingual Forms&lt;br /&gt;
|Implemented and running&lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Completely aligned with  current EU policies &lt;br /&gt;
|runs in production in EU  (one or more MS) &lt;br /&gt;
|Acceptable&lt;br /&gt;
|-&lt;br /&gt;
|13&lt;br /&gt;
|EBSI (CEF Blockchain)&lt;br /&gt;
| style=&amp;quot;background-color:#FFFF00;&amp;quot; Not  stable/ under development &lt;br /&gt;
| style=&amp;quot;background-color:#FFFF00;&amp;quot; Acceptable,  but subject to improvement&lt;br /&gt;
| style=&amp;quot;background-color:#FFFF00;&amp;quot; Piloted &lt;br /&gt;
| style=&amp;quot;background-color:#FFFF00;&amp;quot; Useful&lt;br /&gt;
|-&lt;br /&gt;
|14&lt;br /&gt;
|eInvoicing&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Implemented  and running&lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Completely  aligned with current EU policies &lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | EU  infrastructure, broadly accepted &lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Recommended&lt;br /&gt;
|-&lt;br /&gt;
|15&lt;br /&gt;
|eTranslation&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Implemented  and running&lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Completely  aligned with current EU policies &lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | EU  infrastructure, broadly accepted &lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Recommended&lt;br /&gt;
|-&lt;br /&gt;
|16&lt;br /&gt;
|SEMPER&lt;br /&gt;
| style=&amp;quot;background-color:#FFFF00;&amp;quot; Not  stable/ under development &lt;br /&gt;
| style=&amp;quot;background-color:#FFFF00;&amp;quot; Acceptable,  but subject to improvement&lt;br /&gt;
| style=&amp;quot;background-color:#FFFF00;&amp;quot; Piloted&lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Recommended&lt;br /&gt;
|-&lt;br /&gt;
|17&lt;br /&gt;
|BRIS&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Implemented  and running&lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Completely  aligned with current EU policies &lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | EU  infrastructure, broadly accepted &lt;br /&gt;
| style=&amp;quot;background-color:#FF0000;&amp;quot; | Discarded&lt;br /&gt;
|-&lt;br /&gt;
|18&lt;br /&gt;
|TOOP Architecture&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Implemented and running&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Aligned with national  policies, but is yet to be aligned with the EU&lt;br /&gt;
| style=&amp;quot;background-color:#FFFF00;&amp;quot; Piloted &lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Recommended&lt;br /&gt;
|-&lt;br /&gt;
|19&lt;br /&gt;
|TOOP CERB&lt;br /&gt;
| style=&amp;quot;background-color:#FFFF00;&amp;quot; Not stable/ under  development &lt;br /&gt;
| style=&amp;quot;background-color:#FFFF00;&amp;quot; Acceptable, but subject  to improvement&lt;br /&gt;
| style=&amp;quot;background-color:#FFFF00;&amp;quot; Piloted &lt;br /&gt;
| style=&amp;quot;background-color:#FFFF00;&amp;quot; Useful&lt;br /&gt;
|-&lt;br /&gt;
|20&lt;br /&gt;
|TOOP DSD&lt;br /&gt;
| style=&amp;quot;background-color:#FFFF00;&amp;quot; Not stable/ under  development &lt;br /&gt;
| style=&amp;quot;background-color:#FFFF00;&amp;quot; Acceptable, but subject  to improvement&lt;br /&gt;
| style=&amp;quot;background-color:#FFFF00;&amp;quot; Piloted &lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Acceptable &lt;br /&gt;
|-&lt;br /&gt;
|21&lt;br /&gt;
|TOOP eDelivery [SMP/SML and BDXL]&lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Cutting-edge &lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Aligned with national  policies, but is yet to be aligned with the EU&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | runs in production in EU  (one or more MS) &lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Recommended&lt;br /&gt;
|-&lt;br /&gt;
|22&lt;br /&gt;
|TOOP EDM&lt;br /&gt;
| style=&amp;quot;background-color:#FFFF00;&amp;quot; Not stable/ under development &lt;br /&gt;
| style=&amp;quot;background-color:#FFFF00;&amp;quot; Acceptable, but subject  to improvement&lt;br /&gt;
| style=&amp;quot;background-color:#FF0000;&amp;quot; | Concept &lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Acceptable&lt;br /&gt;
|-&lt;br /&gt;
|23&lt;br /&gt;
|TOOP TC&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Implemented and running&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Aligned with national  policies, but is yet to be aligned with the EU&lt;br /&gt;
| style=&amp;quot;background-color:#FFFF00;&amp;quot; Piloted &lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Recommended&lt;br /&gt;
|-&lt;br /&gt;
|24&lt;br /&gt;
|TOOP Gateway&lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Cutting-edge &lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Aligned with national  policies, but is yet to be aligned with the EU&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | runs in production in EU  (one or more MS) &lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Recommended&lt;br /&gt;
|-&lt;br /&gt;
|25&lt;br /&gt;
|TOOP Testing Tool&lt;br /&gt;
| style=&amp;quot;background-color:#FFFF00;&amp;quot; Not stable/ under  development &lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Acceptable, but subject  to improvement&lt;br /&gt;
| style=&amp;quot;background-color:#FFFF00;&amp;quot; Piloted &lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Acceptable&lt;br /&gt;
|-&lt;br /&gt;
|26&lt;br /&gt;
|ADMS-AP&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Implemented  and running&lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Completely  aligned with current EU policies &lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | EU  infrastructure, broadly accepted &lt;br /&gt;
| style=&amp;quot;background-color:#FFFF00;&amp;quot; Useful&lt;br /&gt;
|-&lt;br /&gt;
|27&lt;br /&gt;
|EDCI&lt;br /&gt;
| style=&amp;quot;background-color:#FFFF00;&amp;quot; Not  stable/ under development &lt;br /&gt;
| style=&amp;quot;background-color:#FFFF00;&amp;quot; Acceptable,  but subject to improvement&lt;br /&gt;
| style=&amp;quot;background-color:#FFFF00;&amp;quot; Piloted&lt;br /&gt;
| style=&amp;quot;background-color:#FFFF00;&amp;quot; Useful&lt;br /&gt;
|-&lt;br /&gt;
|28&lt;br /&gt;
|EES&lt;br /&gt;
| style=&amp;quot;background-color:#FFFF00;&amp;quot; Not  stable/ under development &lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Aligned  with national policies, yet to be aligned with the EU&lt;br /&gt;
| style=&amp;quot;background-color:#FF0000;&amp;quot; | Concept&lt;br /&gt;
| style=&amp;quot;background-color:#FFFF00;&amp;quot; Useful&lt;br /&gt;
|-&lt;br /&gt;
|29&lt;br /&gt;
|eTimeStamp&lt;br /&gt;
| style=&amp;quot;background-color:#FFFF00;&amp;quot; Not  stable/ under development &lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Completely  aligned with current EU policies &lt;br /&gt;
| style=&amp;quot;background-color:#FF0000;&amp;quot; | Concept&lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Recommended&lt;br /&gt;
|-&lt;br /&gt;
|30&lt;br /&gt;
|eDocument&lt;br /&gt;
| style=&amp;quot;background-color:#FFFF00;&amp;quot; Not  stable/ under development &lt;br /&gt;
| style=&amp;quot;background-color:#FFFF00;&amp;quot; Acceptable,  but subject to improvement&lt;br /&gt;
| style=&amp;quot;background-color:#FF0000;&amp;quot; | Concept &lt;br /&gt;
| style=&amp;quot;background-color:#FF0000;&amp;quot; | Discarded&lt;br /&gt;
|-&lt;br /&gt;
|31&lt;br /&gt;
|RPAM&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Implemented  and running&lt;br /&gt;
| style=&amp;quot;background-color:#FFFF00;&amp;quot; Acceptable,  but subject to improvement&lt;br /&gt;
| style=&amp;quot;background-color:#FFFF00;&amp;quot; Piloted &lt;br /&gt;
| style=&amp;quot;background-color:#FFFF00;&amp;quot; Useful&lt;br /&gt;
|-&lt;br /&gt;
|32&lt;br /&gt;
|SMP/SML&lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Cutting-edge &lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Completely  aligned with current EU policies &lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | runs in production in EU  (one or more MS) &lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Recommended&lt;br /&gt;
|-&lt;br /&gt;
|33&lt;br /&gt;
|IMI&lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Cutting-edge &lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Completely  aligned with current EU policies &lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | EU  infrastructure, broadly accepted &lt;br /&gt;
| style=&amp;quot;background-color:#FF0000;&amp;quot; | Discarded&lt;br /&gt;
|}&lt;br /&gt;
Following is the analysis of the results from the overall assessment from the aspect of the pilots’ needs, the conceptual framework and the overall architectural principles. It is important to note that this is not the exhaustive set of gap analysis, but it serves as a proof of concept for the methodological and assessment choices decisions made. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Pilots needs’ considerations'''&lt;br /&gt;
&lt;br /&gt;
From the table above, it can be noted that, although some of the BB are assessed as immature from some aspect, the final recommendation is still for them to be used by the pilots. This is due to the fact that, regardless of the current state of maturity, when matched with the pilots’ requirements, some a BB may still have the necessary architecture capabilities that require adjustment in the DE4A context. For instance, this is the case with SEMPER. The SEMPER extension to eIDAS is not fully mature yet but is the only cross-border functionality for working with proxies that currently mandates successfully piloted. Otherwise, there will be a need to develop a DE4A-specific solution for cross-border powers validation from the scratch, which is bot not useful and not feasible within the project timeframe. In order for SEMPER to gain a broader user-base, it has to be validated by more Member States (currently, it has been piloted with 4 MS). In addition, SEMPER has been piloted with legal persons only. Although this is sufficient to the DBA pilot, this is not the case for the moving abroad and studying abroad, as there is a need for piloting with natural persons. The DE4A pilots themselves may be used for this. Finally, SEMPER extends eIDAS, but has not been handed over to DIGIT yet. Therefore, it has not been incorporated in the eIDAS reference software of DIGIT yet. Integration in eIDAS will improve sustainability of the SEMPER extension. Concretely, SEMPER would benefit from eIDAS-like specifications to allow Member States that do not use the eIDAS reference software to develop their own extension based on these specifications. &lt;br /&gt;
&lt;br /&gt;
In contrast to SEMPER, there is also a case where a BB may be assessed as completely mature in most of the aspects but is still disregarded at the Recommendations stage. This is, for instance, the case with the IMI BB, which despite the overall high maturity in all aspects is out of the scope of the DE4A project. Similarly, the BRIS building block has a scope that is much narrower (especially from an administrative perspective) than the scope of DE4A and is therefore not to be used by the pilots. More concretely, BRIS has been developed for inter-business register communication, which is not the primary focus of the DBA pilot (the functional shortcomings on BRIS for piloting in DBA (D4.5, annex V) have been confirmed by DG DIGIT and there is no BRIS-roadmap foreseen that will deliver a solution to the findings). Furthermore, it is legally not feasible to use the BRIS-network for the DE4A-pilots (currently not allowed for non-business registers). An alternative is being discussed with DIGIT: a message broking platform as a possible future BRIS-wide solution that is piloted in TOOP. However, funding for continuation of the platform is not arranged and the current intention is to bring the (cloud-based) prototype infrastructure down when TOOP testing ends.&lt;br /&gt;
&lt;br /&gt;
Similar reasoning in compiling the overall recommendation score is applied to the other building blocks. These considerations have been discussed in detail at the BB Assessment Group meetings during the Recommendation step of the empirical framework. It is out of scope of the deliverable to present a detailed overview of each BB. However, the subtlety of some of the assessment criteria (such as context dependence) is also an argument to justify the decision to rely only on the experts’ evaluations in the first phase of the methodology.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Assessment outcomes considerations'''&lt;br /&gt;
&lt;br /&gt;
Out of the 33 assessed BB, 13 BB are Recommended for implementation, 9 are Acceptable, 7 are Useful and 4 are Discarded. From a maturity point of view: in terms of technical maturity, 5 are cutting-edge, 18 are implemented and running in an operational environment, whereas 10 are not stable or under development. From an administrative maturity aspect, almost half (17) of the BB are completely aligned with current EU policies; 7 are aligned with national policies but are yet to be consolidated at an EU level, whereas 9 (although acceptable) are still subject to further improvements. &lt;br /&gt;
[[File:Taxonomy of assessed BB with their recommendations .png|alt=Taxonomy of assessed BBs with their recommendations |center|frame|Taxonomy of assessed BB with their recommendations ]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
From operational maturity aspect, there are 8 BB which are broadly accepted as part of an EU infrastructure, 12 that run in production in one or more Member States and 10 that are piloted within some kind of operational or testing environment. It is interesting to note that the only aspect by which a BB has been assessed as immature is the Operational aspect. Thus, there are 4 BB (TOOD EDM, EES, eTimeStamp and eDocument) that are marked as operationally immature, as they are only at the stage of a Concept and are yet to be developed.&lt;br /&gt;
&lt;br /&gt;
From a BB type aspect (also visible in the figure above), most of the recommended BB are of the type ‘Building Block’ (7 out of 13) and ‘Standards and specifications’, whereas the ‘General services’ and the ‘Core service platforms’ are the least numerous and the most immature. This is expected, as the later are also the most complex ones and only few in number across EU. &lt;br /&gt;
&lt;br /&gt;
It is also notable that most of the BB considered for use by the pilots are in a mature and useful state that allows reusability and potential upgrades before implementation in the DE4A pilots. Such considerations are already being made (as discussed in the previous subsection) and are part of the piloting requirements to be assessed in the second phase of the methodology. &lt;br /&gt;
&lt;br /&gt;
'''Architecture framework considerations'''&lt;br /&gt;
&lt;br /&gt;
As outlined in the methodological considerations above, the two phases of the overall methodology follow the Enterprise Architecture Assessment Framework principles, with the additional step of providing recommendations for the pilot in between the two phases. Such an approach allows, in addition to the qualitative evaluation, to obtain e quantitative score for the maturity of the overall architecture as a (sub)set of the assessed BB. In that sense, while the output of the EAAF is a maturity level assessment of the overall architecture, the phased approach in DE4A creates an intermediate feedback loop between the pilots and the Project Start Architecture, allowing for adaptable integration of the assessment methodology within the WP2 change management.&lt;br /&gt;
&lt;br /&gt;
Regardless of the incomplete overall assessment, it is still possible to have a quantitative assessment for a solution architecture after the first assessment phase. However, this is not to be considered as the overall architecture framework maturity level, but only as a ‘current maturity level’ of the solution architecture comprised of a given set of BB. Such value can serve as a reference point to be compared upon a given KPI for the overall maturity, in case there is such requirement.&lt;br /&gt;
&lt;br /&gt;
In order to compile a single value for the current maturity level for a pilot solution architecture, the set of BB assessments and their recommendations shall be compared upon the baseline for the EAAF maturity levels.&lt;br /&gt;
[[File:EAAF Maturity levels.png|alt=EAAF Maturity levels|center|frame|EAAF Maturity levels]]&lt;br /&gt;
In the context of DE4A, we will provide such assessment in the second phase of implementation of this methodology, as currently there is no definite list of BB matched to the specific pilots.&lt;/div&gt;</summary>
		<author><name>Ictu mavi.cristache</name></author>
	</entry>
	<entry>
		<id>https://wiki.de4a.eu/index.php?title=Building_Blocks&amp;diff=3003</id>
		<title>Building Blocks</title>
		<link rel="alternate" type="text/html" href="https://wiki.de4a.eu/index.php?title=Building_Blocks&amp;diff=3003"/>
		<updated>2021-07-15T16:34:55Z</updated>

		<summary type="html">&lt;p&gt;Ictu mavi.cristache: /* Recommendations and Gap Analysis */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The purpose of the Building Blocks (BB) assessment is to assess the suitability of the BB identified and catalogued in Task 1.5 for use within the DE4A project. Thus, it bridges outputs from WP1 and requirements from WP4 to provide input for the technical, operational and administrative considerations in the architectural assessments carried out here. Over 40 BB have been considered for this assessment, 31 of which are assessed at the first phase of this work. The results of the assessment show that there is a mature and acceptable stock of solution building blocks that can be considered as potential candidates for implementation by the pilots, either in their entirety or partially, with the needed upgrades.&lt;br /&gt;
&lt;br /&gt;
== Theoretical background ==&lt;br /&gt;
&lt;br /&gt;
=== Objectives and scope ===&lt;br /&gt;
To reach the goal outlined above, this section delves into the architectural evaluation of the building blocks catalogued as useful for DE4A. It is important to note that the term “building block” in the context of this assessment refers to a Solution Building Block in TOGAF sense. &lt;br /&gt;
&lt;br /&gt;
The most important step in assessing the BB is determining the methodology that would support a common description framework of the BB, while providing means for determining the quantitative and/or qualitative evaluation criteria of the considered BB. The outcome of the assessment is a succinct list of recommendations for BB use by the pilots in WP4. In addition to defining the methodology, a gap analysis is performed based on both the pilots’ requirements and the common description framework of the BB, considering the results from the assessment, the project requirements and the common PSA principles. The overall process of conceptual considerations, empirical evaluation, gap analysis and piloting recommendations are denoted as a DE4A generic methodology for architecture building blocks evaluation.&lt;br /&gt;
&lt;br /&gt;
=== Available methodologies ===&lt;br /&gt;
In order to provide continuity and justification of the methodology that is being developed, we first outline and assess the suitability of the currently available methodologies in view of the implementation context and the objectives of the DE4A project. To that end, both generic EU/EC assessment methodologies and past LSP project-specific methodologies are considered.&lt;br /&gt;
&lt;br /&gt;
==== Common assessment method for standards and specifications (CAMSS) ====&lt;br /&gt;
[https://ec.europa.eu/isa2/solutions/camss_en CAMSS] is part of the ISA² interoperability solutions evaluation toolkit for public administrations, businesses and citizens. It provides a method to assist in the assessment of ICT standards and specifications. The main objective of CAMSS is achieving interoperability and avoiding vendor lock-in. In that sense, CAMSS criteria evaluate (among other things) the openness of standards and specifications. This is done by employing the CAMSS tools and adapting the evaluation according to the needs of an individual Member State.&lt;br /&gt;
&lt;br /&gt;
In the context of DE4A, relying solely on CAMSS does not provide the means for BB suitability and gap analysis in relation to the piloting needs. Moreover, it does not provide any selection criteria or a taxonomy for consistent mapping of the different BB onto a common comparable framework.&lt;br /&gt;
&lt;br /&gt;
==== Past project-specific methodologies ====&lt;br /&gt;
'''eSENS'''&lt;br /&gt;
&lt;br /&gt;
eSENS has developed its own methodology for BB assessment, which is mainly an adaptation of CAMSS and Asset Description Metadata Schema (ADMS), supported by inputs of the [https://web.archive.org/web/20200928232327/http://www.esens.eu/deliverables eSENS deliverable D6.1] (see Table 5 in [https://web.archive.org/web/20200928232327/http://www.esens.eu/deliverables eSENS D3.1]). Its objective is to propose a documentation of format and defining criteria for the maturity and sustainability assessment of building blocks. The overall framework consists of three steps: 1) The Consideration step; 2) The Assessment step; and 3) The Recommendation step and produces a list of assessment criteria to be used for BB evaluation. These criteria, however, are very general and not architecture-specific – their applicability is valid and valuable only if used in collaboration with the legal, business, organizational, technical and implementation team.&lt;br /&gt;
&lt;br /&gt;
It is important to note that the assessment methodology employed in eSENS is developed with a different aim from ours – its analysis and recommendations refer to the desired BB qualities that are needed to ensure meeting the maturity levels and the sustainability criteria envisaged by the project. Thus, although it produces guidelines for assessment, it does not provide concrete output in terms of actual scores, analysis and recommendations for BB. Moreover, it does not provide a comparable baseline when multiple BB have to be considered for the same pilot and it is based on the assumption that the existing BB represent the exhaustive list of possible solutions from which a suitable match should be chosen. In the case of DE4A, such an assumption does not hold, as there may be a case where a certain BB is not mature enough to be recommended for piloting but is also not to be completely disregarded either. More importantly, the methodology developed here is used for actual assessment and is to be fine-tuned at a later stage in connection to the general architecture lifecycle development.&lt;br /&gt;
&lt;br /&gt;
'''TOOP'''&lt;br /&gt;
&lt;br /&gt;
Like eSENS, the overall idea of the TOOP assessment methodology is to reuse existing frameworks and building blocks provided by CEF, eSENS, and other initiatives. First, an initial inventory of existing e- Government building blocks is proposed. Then, the principles of selection of building blocks for OOP applications are provided, together with high-level views of the architecture. Finally, an analysis of selected building blocks is done with respect to their relevance, applicability, sustainability, need for further development and external interfaces.&lt;br /&gt;
&lt;br /&gt;
The main criteria for inclusion of a building block in TOOP are:&lt;br /&gt;
&lt;br /&gt;
* The specific project requirements;&lt;br /&gt;
* The TOOP pilots’ needs;&lt;br /&gt;
* Usability in long-term applications (maintenance and support provided).&lt;br /&gt;
&lt;br /&gt;
As a result, the building blocks are categorized into three basic groups:&lt;br /&gt;
&lt;br /&gt;
# BB that provide capabilities needed by all or most TOOP Pilot Areas;&lt;br /&gt;
# BB that provide capabilities needed or probably needed by some TOOP Pilot Areas;&lt;br /&gt;
# BB that provide capabilities not needed by the TOOP Pilot Areas.&lt;br /&gt;
&lt;br /&gt;
TOOP’s criteria are tightly bound to the piloting needs, whereas the rationale behind their choice is OOP-specific rather than generic. The methodology here follows a similar line of reasoning, but differs in the conceptual framework, which is more formally defined and made reusable by other projects as well. &lt;br /&gt;
&lt;br /&gt;
==== ISA2 Interim Evaluation ====&lt;br /&gt;
The [https://ec.europa.eu/isa2/sites/isa/files/190613_synopsis_report.pdf interim evaluation] aimed to assess how well the ISA² Programme has performed since its start in 2016 and whether its existence continues to be justified. Based on stakeholders’ views, opinions and public consultation, it evaluated the implementation of the programme based on seven criteria and identified several points for improvement. &lt;br /&gt;
&lt;br /&gt;
The evaluation criteria considered were: Relevance (the alignment between the objectives of the programme and the current needs and problems experienced by stakeholders); Effectiveness (the extent to which the programme has achieved its objectives); Efficiency (the extent to which the programme’s objectives are achieved at a minimum cost); Coherence (the alignment between the programme and comparable EU initiatives as well as the overall EU policy framework); EU added value (the additional impacts generated by the programme, as opposed to leaving the subject matter in the hands of Member States); Utility (the extent to which the programme meets stakeholders’ needs); and Sustainability (the likelihood that the programme’s results will last beyond its completion).&lt;br /&gt;
&lt;br /&gt;
However, the interim evaluation does not provide a specific methodology – either in terms of criteria choice, or in terms of architectural or future piloting recommendations. Its value lies mainly in the identification of possible gaps that exist within the current EU architecture framework even prior to the implementation of the available building blocks. In that sense, the main recommendations for prospective actions are determined in awareness raising beyond national administrations; moving from user-centric to user-driven solutions; and working towards increased sustainability.&lt;br /&gt;
&lt;br /&gt;
Our work integrates the interim evaluation criteria even at the stage of cataloguing BB relevant in DE4A context. More importantly, it takes into consideration the methodological gaps identified in the assessment in terms of awareness, user-driven solutions and sustainability prescriptions and integrates specific technical, administrative and operational aspects in the recommendation’s extraction for the pilots. &lt;br /&gt;
&lt;br /&gt;
==== EAAF ====&lt;br /&gt;
The [https://obamawhitehouse.archives.gov/sites/default/files/omb/assets/fea_docs/OMB_EA_Assessment_Framework_v3_1_June_2009.pdf Enterprise Architecture Assessment Framework (EAAF)] assists the US government in the assessment and reporting of their enterprise architecture activity and maturity, as well as in the advancement of the use of enterprise architecture to guide political decisions on IT investments. In addition to providing the methods for the assessment, EAAF also identifies the measurement areas and criteria by which government agencies are to rely on the architecture to drive performance improvements. This is integrated into the so-called Performance Improvement Lifecycle, where points for improvement are identified and translated into specific actions.&lt;br /&gt;
&lt;br /&gt;
In that sense, the framework provides a good overall methodology for the assessment of DE4A BB. Following its guidelines, in order to perform the technical assessment, the architects, together with the relevant project partners (mainly from WP1 and WP4):&lt;br /&gt;
&lt;br /&gt;
* Identify and prioritize the BB considering the pilots’ needs and in view of the project goals and objectives;&lt;br /&gt;
* Determine specific methodological steps for gap analysis, using common or shared information assets and information technology assets;&lt;br /&gt;
* Quantify/qualify and assess the performance to verify compliance with pilots’ requirements and provide report on gap closure; and&lt;br /&gt;
* Assess feedback on the pilots’ performance in order to enhance the architecture and fine-tune the assessment methodology for future implementation decisions.&lt;br /&gt;
&lt;br /&gt;
=== Methodological considerations ===&lt;br /&gt;
The need to develop a generic methodology that integrates some aspects of the standardized methodologies, but does not rely on a single one, is based on several considerations: &lt;br /&gt;
&lt;br /&gt;
# The assessment methodologies currently available either focus on alignment of the BB specifications or are only concerned with the maturity of the solution provided by the building blocks; &lt;br /&gt;
# They do not provide a clear definition of the common principles for assessment;&lt;br /&gt;
# They do not allow for a phased-approach to the assessment and are applicable either for a single BB or for a finalized solution architecture (Note: Although EAAF prescribes the principles for a phased assessment, it does not delineate the phases explicitly and only gives a requirement for the overall outcome of the assessment). &lt;br /&gt;
&lt;br /&gt;
As a result, the architect is prevented from developing an assessment for multiple BB with varying levels of complexity and is also disabled to perform comparative evaluation for determining the best fit for a particular solution architecture. &lt;br /&gt;
&lt;br /&gt;
The methodology developed here is novel in that it addresses the points above and is also generic in the sense that it can be reused by other large-scale projects for similar purposes. It incorporates the assessment principles of existing standards-based methodologies (like CAMSS and EAAF) taking into account the architecture feasibility and sustainability, but it also generalizes these principles over the context of implementation required by DE4A.&lt;br /&gt;
&lt;br /&gt;
== Methodology ==&lt;br /&gt;
In order to account for both the piloting recommendations criteria and the performance assessment criteria, the overall methodology requires a phased approach. Therefore, it consists of two phases:&lt;br /&gt;
&lt;br /&gt;
I) The first phase takes stock of the entire list of BB that can have potential use in the project and as part of the piloting. Then, a conceptual and an empirical framework for evaluation is developed – the former enables the gap analysis of the BB, whereas the latter allows for qualitative and comparative analysis of the BB, as well as extraction of concrete recommendations for piloting. The first phase essentially corresponds to the first three points of the EAAF.&lt;br /&gt;
&lt;br /&gt;
II) The second phase will account for the complete list of project artefacts and will provide empirical validation for the results and recommendations from the first phase. In addition, reassessment of the previous gaps will be performed. This phase will mainly be realized in close collaboration with the pilots: direct feedback via surveys and questionnaires on BB performance will be obtained and the initial conceptual framework will be fine-tuned accordingly. The second phase corresponds to the last point of the EAAF.&lt;br /&gt;
&lt;br /&gt;
=== Conceptual framework ===&lt;br /&gt;
In this section, we first catalogue the BB that are to be considered by the assessment. This step considers the output from D1.5 and establishes a relation to the internal project environment. Then we establish a common conceptualization of the key elements, which is based on the Digital service model, Section 2.2 of the Study on &amp;quot;The feasibility and scenarios for the long-term sustainability of the Large Scale Pilots”. With that, a relation to the external project environment is established. Finally, a basic assessment framework is developed to enable the grading of the BB from several maturity aspects: technical, administrative and operational. The output of the assessment will allow us to perform gap analysis and will also guide the extraction of the piloting recommendations.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''The Digital Services Model: A five-layered approach'''&lt;br /&gt;
&lt;br /&gt;
The LSPs so far have developed building blocks that enable cross-border interoperability based on standards, specifications and common code/components. Therefore, moving beyond the pilot projects and towards actual deployment, it is crucial to develop a structure in which the digital services and the elements they are composed of can be conceptualized.&lt;br /&gt;
&lt;br /&gt;
To establish a conceptual model, it is important to clearly set out the key terminology that is used in relation to the DSI for the provision of cross-border public services. CEF provides an overarching framework suitable for this purpose, called Digital Services Model (DSM). It takes into account the deliverables of the LSPs, the stakeholders and roles they can take on, and the drivers behind the dynamics of this complex ecosystem.&lt;br /&gt;
&lt;br /&gt;
The Digital Services Model is not only needed to establish common terminology and framework, but it is also necessary to analyse the needs and requirements for the future deployment of any digital services, enabling a continuity of the developed methodologies with the LSPs. Thus, it presents the different levels of granularity which need to be taken into consideration for the overall management of the DSI for the provision of public Services.&lt;br /&gt;
&lt;br /&gt;
The following elements represent the main part of the DSM taxonomy:&lt;br /&gt;
&lt;br /&gt;
# Standards and Specifications;&lt;br /&gt;
# Common code or Components;&lt;br /&gt;
# Building Blocks;&lt;br /&gt;
# Core Service Platforms;&lt;br /&gt;
# Generic Services.&lt;br /&gt;
&lt;br /&gt;
Standards and Specifications have been used by all the LSPs for the development of the digital services. These standards and specifications play a central role in interoperability as it means that systems have commonalities in key areas, enabling systems to communicate with one another.&lt;br /&gt;
&lt;br /&gt;
Components are the common code that has been developed for the building blocks. Building blocks are made up of several components (e.g. a timestamp component/functionality). These are often referred to as modules in the deliverables of the LSPs. Component can either be BB-specific or used in several BB.&lt;br /&gt;
&lt;br /&gt;
Essentially, all the solutions derived from the LSPs are ultimately building blocks in the sense that they are services that can be integrated as part of other services. Given the fact that these building blocks have the most obvious potential for reuse across different domains (or Core Service Platforms) these can be seen as a specific layer as part of the set of digital services.&lt;br /&gt;
&lt;br /&gt;
Core Service Platforms enable the provision of cross-border digital services in different domains, like eHealth, eJustice and eProcurement. These are the platforms where all the different BB for a specific service (e.g. eHealth services or eID services) are brought together and made available, enabling service providers to take up and reuse the services as part of their own services. The Core Service Platform (CSP) level should eventually enable the Member States to interact with other Member States through the use of building blocks (via the Generic Services).&lt;br /&gt;
&lt;br /&gt;
It is important to determine what building blocks have been developed by an LSP, as well as which of these are CSP-specific and which are reusable. The CSP-specific blocks are called domain blocks (e.g. ePrescription is specific to eHealth) and the reusable blocks are called building blocks (e.g. eID can be reused in various domains).&lt;br /&gt;
&lt;br /&gt;
The reusable building blocks are the strongest common element between the various CSPs. They therefore need to meet the needs and requirements of all the CSPs. This underlines the links between the building blocks and the CSPs, and the need to manage both of these simultaneously.&lt;br /&gt;
&lt;br /&gt;
Generic Services is the level of abstraction at which the Member States integrate or connect to the CSPs. These interconnections are necessary to link up a Member State so it can provide cross-border access and use of national eIDs, electronic health records, national procurement platforms, national eJustice platforms and public services for foreign business. Each Member State has to ensure that these existing systems at national level are linked up with the CSPs through Generic Services in order to be cross-border enabled.&lt;br /&gt;
&lt;br /&gt;
To define a common taxonomy for BB description prior to the actual assessment, the relevant BB are catalogued in view of the five-layered model described above. This is represented in the figure below (Taxonomy of Building Blocks). &lt;br /&gt;
[[File:Taxonomy of Building Blocks.png|alt=Taxonomy of Building Blocks|Taxonomy of Building Blocks|center|frame]]Although implicitly understandable, it is worth noting that some BB can belong to two different categories, as their application is largely context dependent. In other words, whereas in one context a certain BB can be seen as a Standard/Specification, in another context it can be a Component. In those cases, the more general category is assigned to that BB, giving priority to show its potential rather than its most common use. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Assessment criteria'''&lt;br /&gt;
&lt;br /&gt;
In this section, a basic assessment framework is presented composed of the criteria that guide the expert scoring of BB from the aspect of technical, administrative and operational maturity. The criteria essentially represent a matrix indexed by two dimensions: Score and Maturity aspect. These dimensions, together with the semantics of the criteria (the matrix-cells) are shown in the table below (Conceptual BB assessment framework). For better graphical representation of the empirical assessment that will be performed in the next section, each row is represented by a colour, visually grasping the overall maturity of a certain building block.&lt;br /&gt;
[[File:Conceptual BB assessment framework.png|alt=Conceptual BB assessment framework|center|thumb|600x600px|Conceptual BB assessment framework]]&lt;br /&gt;
The colouring of the framework is not important only for the visual appeal of the reader; rather, it is meant to serve as a concrete input (an additional dimension) for the prospective formalization of the assessment framework. Such formalization would enable a semi- and, ultimately, a fully automatic maturity and quality attributes assessment of both a set of desired (composable) BB, as well as a solution architecture representing a Common Service Platform or a General Service per se. &lt;br /&gt;
&lt;br /&gt;
It is important to note that the framework represented above is a simplified version of the generic assessment framework that will be the final contribution by WP2. This is because at this stage it cannot be expected that all necessary information by the pilots is obtained for an overall architecture evaluation to take place. Such assessment will be performed in the second phase of the ''BB assessment'' task, when the framework from Table 2 will also be further revised and fine-tuned. As a result, the gap analysis in the second phase will take into account the exhaustive set of pilots’ requirements and the pilots’ feedback on the implemented BB.&lt;br /&gt;
&lt;br /&gt;
=== Empirical framework ===&lt;br /&gt;
The empirical framework is essentially an implementation of the conceptual framework with concrete recommendations as an output. While the conceptual framework is based on well-standardized assessment methodologies, the (input to the) empirical evaluation of the BB relies largely on expert opinions and judgements. To close the subjectivity gap between the experts’ evaluation criteria, the BB Assessment group defined an internal process of iterative calibration on the evaluation criteria, as represented by the process flow below:&lt;br /&gt;
[[File:Calibration process for BB evaluation criteria.png|alt=Calibration process for BB evaluation criteria|center|thumb|600x600px|Calibration process for BB evaluation criteria]]&lt;br /&gt;
In the '''Preparatory step''', the building blocks were matched to the experts’ experience and expertise with respect to the capabilities provided by each BB and the architecture principles outlined by the DE4A objectives. One or more groups of BB with shared capabilities were then assigned to each expert for assessment.  &lt;br /&gt;
&lt;br /&gt;
In the '''Assessment step''', the initial evaluation criteria were agreed upon and integrated into the [https://wiki.de4a.eu/index.php/File:Conceptual_BB_assessment_framework.png basic assessment framework]. Then, the results from the initial assessments for each BB were presented in front of the BB Assessment group. This allowed for a constructive discussion on the need to fine-tune the evaluation criteria and to revise the evaluation results. These considerations are part of the '''Fine-tuning step''', which is essentially an iterative procedure on its own, until the complete set of evaluation criteria is obtained, and the BB scores are approved by all experts of the BB Assessment group.&lt;br /&gt;
&lt;br /&gt;
In the '''Recommendation step''', the final scores for each BB were provided for all three maturity aspects: Technical, Administrative and Operational. These are then analysed in view of the piloting requirements and the DE4A objectives as part of the Gap analysis, enabling the extraction of a single Recommendation as an output from the overall process.&lt;br /&gt;
&lt;br /&gt;
The output of the preparatory step is the Taxonomy of BB, whereas the output of the Assessment step is the conceptual framework – further whose criteria, aspects and semantics were fine-tuned in the third step. The scores and recommendations are obtained as an output from the final (Recommendation) step, supported by the argumentation given in the Gap Analysis. For a more complete overview of the final scores and recommendation, they are succinctly represented altogether in the BB recommendations table below. &lt;br /&gt;
&lt;br /&gt;
=== Recommendations and Gap Analysis ===&lt;br /&gt;
This section summarizes the assessment for each building block, by aspect and with an overall recommendation grade. A recommendation is essentially the expert opinion based on the results from the conceptual framework, the gap analysis and in relation to the piloting needs and requirements. The overall list of assessed BB is catalogued as follows:&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|+BB recommendations&lt;br /&gt;
|'''#'''&lt;br /&gt;
|'''Building Block'''&lt;br /&gt;
|'''Technical Maturity'''&lt;br /&gt;
|'''Administrative Maturity'''&lt;br /&gt;
|'''Operational Maturity'''&lt;br /&gt;
|'''Recommendation'''&lt;br /&gt;
|-&lt;br /&gt;
|1&lt;br /&gt;
|eDelivery&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Implemented  and running&lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Completely  aligned with current EU policies &lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | runs  in production in EU (one or more MS) &lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Recommended&lt;br /&gt;
|-&lt;br /&gt;
|2&lt;br /&gt;
|eID&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Implemented  and running&lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Completely  aligned with current EU policies &lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | runs  in production in EU (one or more MS) &lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Recommended&lt;br /&gt;
|-&lt;br /&gt;
|3&lt;br /&gt;
|eSignature&lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Cutting-edge &lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Completely  aligned with current EU policies &lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | runs  in production in EU (one or more MS) &lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Recommended&lt;br /&gt;
|-&lt;br /&gt;
|4&lt;br /&gt;
|CCCEV&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Implemented  and running&lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Completely  aligned with current EU policies &lt;br /&gt;
|Piloted &lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Acceptable&lt;br /&gt;
|-&lt;br /&gt;
|5&lt;br /&gt;
|CPSV-AP&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Implemented  and running&lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Completely  aligned with current EU policies &lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | runs  in production in EU (one or more MS) &lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Acceptable&lt;br /&gt;
|-&lt;br /&gt;
|6&lt;br /&gt;
|eCertis&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Implemented  and running&lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Completely  aligned with current EU policies &lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | EU  infrastructure, broadly accepted &lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Recommended&lt;br /&gt;
|-&lt;br /&gt;
|7&lt;br /&gt;
|eIDAS interoperability  specifications&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Implemented  and running&lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Completely  aligned with current EU policies &lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | runs  in production in EU (one or more MS) &lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Acceptable&lt;br /&gt;
|-&lt;br /&gt;
|8&lt;br /&gt;
|sTESTA&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Implemented  and running&lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Completely  aligned with current EU policies &lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | EU  infrastructure, broadly accepted &lt;br /&gt;
|Discarded&lt;br /&gt;
|-&lt;br /&gt;
|9&lt;br /&gt;
|x-Road&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Implemented  and running&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Aligned  with national policies, but is yet to be aligned with the EU&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | runs  in production in EU (one or more MS) &lt;br /&gt;
|Useful&lt;br /&gt;
|-&lt;br /&gt;
|10&lt;br /&gt;
|DCAT-AP&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Implemented  and running&lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Completely  aligned with current EU policies &lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | EU  infrastructure, broadly accepted &lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Acceptable&lt;br /&gt;
|-&lt;br /&gt;
|11&lt;br /&gt;
|BREG-DCAT-AP &lt;br /&gt;
|Not  stable/ under development &lt;br /&gt;
|Acceptable,  but subject to improvement&lt;br /&gt;
|Piloted&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Acceptable&lt;br /&gt;
|-&lt;br /&gt;
|12&lt;br /&gt;
|ISA2 Multilingual Forms&lt;br /&gt;
|Implemented and running&lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Completely aligned with  current EU policies &lt;br /&gt;
|runs in production in EU  (one or more MS) &lt;br /&gt;
|Acceptable&lt;br /&gt;
|-&lt;br /&gt;
|13&lt;br /&gt;
|EBSI (CEF Blockchain)&lt;br /&gt;
|Not  stable/ under development &lt;br /&gt;
|Acceptable,  but subject to improvement&lt;br /&gt;
|Piloted &lt;br /&gt;
|Useful&lt;br /&gt;
|-&lt;br /&gt;
|14&lt;br /&gt;
|eInvoicing&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Implemented  and running&lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Completely  aligned with current EU policies &lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | EU  infrastructure, broadly accepted &lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Recommended&lt;br /&gt;
|-&lt;br /&gt;
|15&lt;br /&gt;
|eTranslation&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Implemented  and running&lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Completely  aligned with current EU policies &lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | EU  infrastructure, broadly accepted &lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Recommended&lt;br /&gt;
|-&lt;br /&gt;
|16&lt;br /&gt;
|SEMPER&lt;br /&gt;
|Not  stable/ under development &lt;br /&gt;
|Acceptable,  but subject to improvement&lt;br /&gt;
|Piloted&lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Recommended&lt;br /&gt;
|-&lt;br /&gt;
|17&lt;br /&gt;
|BRIS&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Implemented  and running&lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Completely  aligned with current EU policies &lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | EU  infrastructure, broadly accepted &lt;br /&gt;
|Discarded&lt;br /&gt;
|-&lt;br /&gt;
|18&lt;br /&gt;
|TOOP Architecture&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Implemented and running&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Aligned with national  policies, but is yet to be aligned with the EU&lt;br /&gt;
|Piloted &lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Recommended&lt;br /&gt;
|-&lt;br /&gt;
|19&lt;br /&gt;
|TOOP CERB&lt;br /&gt;
|Not stable/ under  development &lt;br /&gt;
|Acceptable, but subject  to improvement&lt;br /&gt;
|Piloted &lt;br /&gt;
|Useful&lt;br /&gt;
|-&lt;br /&gt;
|20&lt;br /&gt;
|TOOP DSD&lt;br /&gt;
|Not stable/ under  development &lt;br /&gt;
|Acceptable, but subject  to improvement&lt;br /&gt;
|Piloted &lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Acceptable &lt;br /&gt;
|-&lt;br /&gt;
|21&lt;br /&gt;
|TOOP eDelivery [SMP/SML and BDXL]&lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Cutting-edge &lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Aligned with national  policies, but is yet to be aligned with the EU&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | runs in production in EU  (one or more MS) &lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Recommended&lt;br /&gt;
|-&lt;br /&gt;
|22&lt;br /&gt;
|TOOP EDM&lt;br /&gt;
|Not stable/ under development &lt;br /&gt;
|Acceptable, but subject  to improvement&lt;br /&gt;
|Concept &lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Acceptable&lt;br /&gt;
|-&lt;br /&gt;
|23&lt;br /&gt;
|TOOP TC&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Implemented and running&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Aligned with national  policies, but is yet to be aligned with the EU&lt;br /&gt;
|Piloted &lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Recommended&lt;br /&gt;
|-&lt;br /&gt;
|24&lt;br /&gt;
|TOOP Gateway&lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Cutting-edge &lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Aligned with national  policies, but is yet to be aligned with the EU&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | runs in production in EU  (one or more MS) &lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Recommended&lt;br /&gt;
|-&lt;br /&gt;
|25&lt;br /&gt;
|TOOP Testing Tool&lt;br /&gt;
|Not stable/ under  development &lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Acceptable, but subject  to improvement&lt;br /&gt;
|Piloted &lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Acceptable&lt;br /&gt;
|-&lt;br /&gt;
|26&lt;br /&gt;
|ADMS-AP&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Implemented  and running&lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Completely  aligned with current EU policies &lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | EU  infrastructure, broadly accepted &lt;br /&gt;
|Useful&lt;br /&gt;
|-&lt;br /&gt;
|27&lt;br /&gt;
|EDCI&lt;br /&gt;
|Not  stable/ under development &lt;br /&gt;
|Acceptable,  but subject to improvement&lt;br /&gt;
|Piloted&lt;br /&gt;
|&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Useful&lt;br /&gt;
|-&lt;br /&gt;
|28&lt;br /&gt;
|EES&lt;br /&gt;
|Not  stable/ under development &lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Aligned  with national policies, yet to be aligned with the EU&lt;br /&gt;
|Concept&lt;br /&gt;
|Useful&lt;br /&gt;
|-&lt;br /&gt;
|29&lt;br /&gt;
|eTimeStamp&lt;br /&gt;
|Not  stable/ under development &lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Completely  aligned with current EU policies &lt;br /&gt;
|Concept&lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Recommended&lt;br /&gt;
|-&lt;br /&gt;
|30&lt;br /&gt;
|eDocument&lt;br /&gt;
|Not  stable/ under development &lt;br /&gt;
|Acceptable,  but subject to improvement&lt;br /&gt;
|Concept &lt;br /&gt;
|Discarded&lt;br /&gt;
|-&lt;br /&gt;
|31&lt;br /&gt;
|RPAM&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Implemented  and running&lt;br /&gt;
|Acceptable,  but subject to improvement&lt;br /&gt;
|Piloted &lt;br /&gt;
|Useful&lt;br /&gt;
|-&lt;br /&gt;
|32&lt;br /&gt;
|SMP/SML&lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Cutting-edge &lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Completely  aligned with current EU policies &lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | runs in production in EU  (one or more MS) &lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Recommended&lt;br /&gt;
|-&lt;br /&gt;
|33&lt;br /&gt;
|IMI&lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Cutting-edge &lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | Completely  aligned with current EU policies &lt;br /&gt;
| style=&amp;quot;background-color:#00B050;&amp;quot; | EU  infrastructure, broadly accepted &lt;br /&gt;
|Discarded&lt;br /&gt;
|}&lt;br /&gt;
Following is the analysis of the results from the overall assessment from the aspect of the pilots’ needs, the conceptual framework and the overall architectural principles. It is important to note that this is not the exhaustive set of gap analysis, but it serves as a proof of concept for the methodological and assessment choices decisions made. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Pilots needs’ considerations'''&lt;br /&gt;
&lt;br /&gt;
From the table above, it can be noted that, although some of the BB are assessed as immature from some aspect, the final recommendation is still for them to be used by the pilots. This is due to the fact that, regardless of the current state of maturity, when matched with the pilots’ requirements, some a BB may still have the necessary architecture capabilities that require adjustment in the DE4A context. For instance, this is the case with SEMPER. The SEMPER extension to eIDAS is not fully mature yet but is the only cross-border functionality for working with proxies that currently mandates successfully piloted. Otherwise, there will be a need to develop a DE4A-specific solution for cross-border powers validation from the scratch, which is bot not useful and not feasible within the project timeframe. In order for SEMPER to gain a broader user-base, it has to be validated by more Member States (currently, it has been piloted with 4 MS). In addition, SEMPER has been piloted with legal persons only. Although this is sufficient to the DBA pilot, this is not the case for the moving abroad and studying abroad, as there is a need for piloting with natural persons. The DE4A pilots themselves may be used for this. Finally, SEMPER extends eIDAS, but has not been handed over to DIGIT yet. Therefore, it has not been incorporated in the eIDAS reference software of DIGIT yet. Integration in eIDAS will improve sustainability of the SEMPER extension. Concretely, SEMPER would benefit from eIDAS-like specifications to allow Member States that do not use the eIDAS reference software to develop their own extension based on these specifications. &lt;br /&gt;
&lt;br /&gt;
In contrast to SEMPER, there is also a case where a BB may be assessed as completely mature in most of the aspects but is still disregarded at the Recommendations stage. This is, for instance, the case with the IMI BB, which despite the overall high maturity in all aspects is out of the scope of the DE4A project. Similarly, the BRIS building block has a scope that is much narrower (especially from an administrative perspective) than the scope of DE4A and is therefore not to be used by the pilots. More concretely, BRIS has been developed for inter-business register communication, which is not the primary focus of the DBA pilot (the functional shortcomings on BRIS for piloting in DBA (D4.5, annex V) have been confirmed by DG DIGIT and there is no BRIS-roadmap foreseen that will deliver a solution to the findings). Furthermore, it is legally not feasible to use the BRIS-network for the DE4A-pilots (currently not allowed for non-business registers). An alternative is being discussed with DIGIT: a message broking platform as a possible future BRIS-wide solution that is piloted in TOOP. However, funding for continuation of the platform is not arranged and the current intention is to bring the (cloud-based) prototype infrastructure down when TOOP testing ends.&lt;br /&gt;
&lt;br /&gt;
Similar reasoning in compiling the overall recommendation score is applied to the other building blocks. These considerations have been discussed in detail at the BB Assessment Group meetings during the Recommendation step of the empirical framework. It is out of scope of the deliverable to present a detailed overview of each BB. However, the subtlety of some of the assessment criteria (such as context dependence) is also an argument to justify the decision to rely only on the experts’ evaluations in the first phase of the methodology.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Assessment outcomes considerations'''&lt;br /&gt;
&lt;br /&gt;
Out of the 33 assessed BB, 13 BB are Recommended for implementation, 9 are Acceptable, 7 are Useful and 4 are Discarded. From a maturity point of view: in terms of technical maturity, 5 are cutting-edge, 18 are implemented and running in an operational environment, whereas 10 are not stable or under development. From an administrative maturity aspect, almost half (17) of the BB are completely aligned with current EU policies; 7 are aligned with national policies but are yet to be consolidated at an EU level, whereas 9 (although acceptable) are still subject to further improvements. &lt;br /&gt;
[[File:Taxonomy of assessed BB with their recommendations .png|alt=Taxonomy of assessed BBs with their recommendations |center|frame|Taxonomy of assessed BB with their recommendations ]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
From operational maturity aspect, there are 8 BB which are broadly accepted as part of an EU infrastructure, 12 that run in production in one or more Member States and 10 that are piloted within some kind of operational or testing environment. It is interesting to note that the only aspect by which a BB has been assessed as immature is the Operational aspect. Thus, there are 4 BB (TOOD EDM, EES, eTimeStamp and eDocument) that are marked as operationally immature, as they are only at the stage of a Concept and are yet to be developed.&lt;br /&gt;
&lt;br /&gt;
From a BB type aspect (also visible in the figure above), most of the recommended BB are of the type ‘Building Block’ (7 out of 13) and ‘Standards and specifications’, whereas the ‘General services’ and the ‘Core service platforms’ are the least numerous and the most immature. This is expected, as the later are also the most complex ones and only few in number across EU. &lt;br /&gt;
&lt;br /&gt;
It is also notable that most of the BB considered for use by the pilots are in a mature and useful state that allows reusability and potential upgrades before implementation in the DE4A pilots. Such considerations are already being made (as discussed in the previous subsection) and are part of the piloting requirements to be assessed in the second phase of the methodology. &lt;br /&gt;
&lt;br /&gt;
'''Architecture framework considerations'''&lt;br /&gt;
&lt;br /&gt;
As outlined in the methodological considerations above, the two phases of the overall methodology follow the Enterprise Architecture Assessment Framework principles, with the additional step of providing recommendations for the pilot in between the two phases. Such an approach allows, in addition to the qualitative evaluation, to obtain e quantitative score for the maturity of the overall architecture as a (sub)set of the assessed BB. In that sense, while the output of the EAAF is a maturity level assessment of the overall architecture, the phased approach in DE4A creates an intermediate feedback loop between the pilots and the Project Start Architecture, allowing for adaptable integration of the assessment methodology within the WP2 change management.&lt;br /&gt;
&lt;br /&gt;
Regardless of the incomplete overall assessment, it is still possible to have a quantitative assessment for a solution architecture after the first assessment phase. However, this is not to be considered as the overall architecture framework maturity level, but only as a ‘current maturity level’ of the solution architecture comprised of a given set of BB. Such value can serve as a reference point to be compared upon a given KPI for the overall maturity, in case there is such requirement.&lt;br /&gt;
&lt;br /&gt;
In order to compile a single value for the current maturity level for a pilot solution architecture, the set of BB assessments and their recommendations shall be compared upon the baseline for the EAAF maturity levels.&lt;br /&gt;
[[File:EAAF Maturity levels.png|alt=EAAF Maturity levels|center|frame|EAAF Maturity levels]]&lt;br /&gt;
In the context of DE4A, we will provide such assessment in the second phase of implementation of this methodology, as currently there is no definite list of BB matched to the specific pilots.&lt;/div&gt;</summary>
		<author><name>Ictu mavi.cristache</name></author>
	</entry>
	<entry>
		<id>https://wiki.de4a.eu/index.php?title=Building_Blocks&amp;diff=3002</id>
		<title>Building Blocks</title>
		<link rel="alternate" type="text/html" href="https://wiki.de4a.eu/index.php?title=Building_Blocks&amp;diff=3002"/>
		<updated>2021-07-15T16:31:22Z</updated>

		<summary type="html">&lt;p&gt;Ictu mavi.cristache: /* Recommendations and Gap Analysis */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The purpose of the Building Blocks (BB) assessment is to assess the suitability of the BB identified and catalogued in Task 1.5 for use within the DE4A project. Thus, it bridges outputs from WP1 and requirements from WP4 to provide input for the technical, operational and administrative considerations in the architectural assessments carried out here. Over 40 BB have been considered for this assessment, 31 of which are assessed at the first phase of this work. The results of the assessment show that there is a mature and acceptable stock of solution building blocks that can be considered as potential candidates for implementation by the pilots, either in their entirety or partially, with the needed upgrades.&lt;br /&gt;
&lt;br /&gt;
== Theoretical background ==&lt;br /&gt;
&lt;br /&gt;
=== Objectives and scope ===&lt;br /&gt;
To reach the goal outlined above, this section delves into the architectural evaluation of the building blocks catalogued as useful for DE4A. It is important to note that the term “building block” in the context of this assessment refers to a Solution Building Block in TOGAF sense. &lt;br /&gt;
&lt;br /&gt;
The most important step in assessing the BB is determining the methodology that would support a common description framework of the BB, while providing means for determining the quantitative and/or qualitative evaluation criteria of the considered BB. The outcome of the assessment is a succinct list of recommendations for BB use by the pilots in WP4. In addition to defining the methodology, a gap analysis is performed based on both the pilots’ requirements and the common description framework of the BB, considering the results from the assessment, the project requirements and the common PSA principles. The overall process of conceptual considerations, empirical evaluation, gap analysis and piloting recommendations are denoted as a DE4A generic methodology for architecture building blocks evaluation.&lt;br /&gt;
&lt;br /&gt;
=== Available methodologies ===&lt;br /&gt;
In order to provide continuity and justification of the methodology that is being developed, we first outline and assess the suitability of the currently available methodologies in view of the implementation context and the objectives of the DE4A project. To that end, both generic EU/EC assessment methodologies and past LSP project-specific methodologies are considered.&lt;br /&gt;
&lt;br /&gt;
==== Common assessment method for standards and specifications (CAMSS) ====&lt;br /&gt;
[https://ec.europa.eu/isa2/solutions/camss_en CAMSS] is part of the ISA² interoperability solutions evaluation toolkit for public administrations, businesses and citizens. It provides a method to assist in the assessment of ICT standards and specifications. The main objective of CAMSS is achieving interoperability and avoiding vendor lock-in. In that sense, CAMSS criteria evaluate (among other things) the openness of standards and specifications. This is done by employing the CAMSS tools and adapting the evaluation according to the needs of an individual Member State.&lt;br /&gt;
&lt;br /&gt;
In the context of DE4A, relying solely on CAMSS does not provide the means for BB suitability and gap analysis in relation to the piloting needs. Moreover, it does not provide any selection criteria or a taxonomy for consistent mapping of the different BB onto a common comparable framework.&lt;br /&gt;
&lt;br /&gt;
==== Past project-specific methodologies ====&lt;br /&gt;
'''eSENS'''&lt;br /&gt;
&lt;br /&gt;
eSENS has developed its own methodology for BB assessment, which is mainly an adaptation of CAMSS and Asset Description Metadata Schema (ADMS), supported by inputs of the [https://web.archive.org/web/20200928232327/http://www.esens.eu/deliverables eSENS deliverable D6.1] (see Table 5 in [https://web.archive.org/web/20200928232327/http://www.esens.eu/deliverables eSENS D3.1]). Its objective is to propose a documentation of format and defining criteria for the maturity and sustainability assessment of building blocks. The overall framework consists of three steps: 1) The Consideration step; 2) The Assessment step; and 3) The Recommendation step and produces a list of assessment criteria to be used for BB evaluation. These criteria, however, are very general and not architecture-specific – their applicability is valid and valuable only if used in collaboration with the legal, business, organizational, technical and implementation team.&lt;br /&gt;
&lt;br /&gt;
It is important to note that the assessment methodology employed in eSENS is developed with a different aim from ours – its analysis and recommendations refer to the desired BB qualities that are needed to ensure meeting the maturity levels and the sustainability criteria envisaged by the project. Thus, although it produces guidelines for assessment, it does not provide concrete output in terms of actual scores, analysis and recommendations for BB. Moreover, it does not provide a comparable baseline when multiple BB have to be considered for the same pilot and it is based on the assumption that the existing BB represent the exhaustive list of possible solutions from which a suitable match should be chosen. In the case of DE4A, such an assumption does not hold, as there may be a case where a certain BB is not mature enough to be recommended for piloting but is also not to be completely disregarded either. More importantly, the methodology developed here is used for actual assessment and is to be fine-tuned at a later stage in connection to the general architecture lifecycle development.&lt;br /&gt;
&lt;br /&gt;
'''TOOP'''&lt;br /&gt;
&lt;br /&gt;
Like eSENS, the overall idea of the TOOP assessment methodology is to reuse existing frameworks and building blocks provided by CEF, eSENS, and other initiatives. First, an initial inventory of existing e- Government building blocks is proposed. Then, the principles of selection of building blocks for OOP applications are provided, together with high-level views of the architecture. Finally, an analysis of selected building blocks is done with respect to their relevance, applicability, sustainability, need for further development and external interfaces.&lt;br /&gt;
&lt;br /&gt;
The main criteria for inclusion of a building block in TOOP are:&lt;br /&gt;
&lt;br /&gt;
* The specific project requirements;&lt;br /&gt;
* The TOOP pilots’ needs;&lt;br /&gt;
* Usability in long-term applications (maintenance and support provided).&lt;br /&gt;
&lt;br /&gt;
As a result, the building blocks are categorized into three basic groups:&lt;br /&gt;
&lt;br /&gt;
# BB that provide capabilities needed by all or most TOOP Pilot Areas;&lt;br /&gt;
# BB that provide capabilities needed or probably needed by some TOOP Pilot Areas;&lt;br /&gt;
# BB that provide capabilities not needed by the TOOP Pilot Areas.&lt;br /&gt;
&lt;br /&gt;
TOOP’s criteria are tightly bound to the piloting needs, whereas the rationale behind their choice is OOP-specific rather than generic. The methodology here follows a similar line of reasoning, but differs in the conceptual framework, which is more formally defined and made reusable by other projects as well. &lt;br /&gt;
&lt;br /&gt;
==== ISA2 Interim Evaluation ====&lt;br /&gt;
The [https://ec.europa.eu/isa2/sites/isa/files/190613_synopsis_report.pdf interim evaluation] aimed to assess how well the ISA² Programme has performed since its start in 2016 and whether its existence continues to be justified. Based on stakeholders’ views, opinions and public consultation, it evaluated the implementation of the programme based on seven criteria and identified several points for improvement. &lt;br /&gt;
&lt;br /&gt;
The evaluation criteria considered were: Relevance (the alignment between the objectives of the programme and the current needs and problems experienced by stakeholders); Effectiveness (the extent to which the programme has achieved its objectives); Efficiency (the extent to which the programme’s objectives are achieved at a minimum cost); Coherence (the alignment between the programme and comparable EU initiatives as well as the overall EU policy framework); EU added value (the additional impacts generated by the programme, as opposed to leaving the subject matter in the hands of Member States); Utility (the extent to which the programme meets stakeholders’ needs); and Sustainability (the likelihood that the programme’s results will last beyond its completion).&lt;br /&gt;
&lt;br /&gt;
However, the interim evaluation does not provide a specific methodology – either in terms of criteria choice, or in terms of architectural or future piloting recommendations. Its value lies mainly in the identification of possible gaps that exist within the current EU architecture framework even prior to the implementation of the available building blocks. In that sense, the main recommendations for prospective actions are determined in awareness raising beyond national administrations; moving from user-centric to user-driven solutions; and working towards increased sustainability.&lt;br /&gt;
&lt;br /&gt;
Our work integrates the interim evaluation criteria even at the stage of cataloguing BB relevant in DE4A context. More importantly, it takes into consideration the methodological gaps identified in the assessment in terms of awareness, user-driven solutions and sustainability prescriptions and integrates specific technical, administrative and operational aspects in the recommendation’s extraction for the pilots. &lt;br /&gt;
&lt;br /&gt;
==== EAAF ====&lt;br /&gt;
The [https://obamawhitehouse.archives.gov/sites/default/files/omb/assets/fea_docs/OMB_EA_Assessment_Framework_v3_1_June_2009.pdf Enterprise Architecture Assessment Framework (EAAF)] assists the US government in the assessment and reporting of their enterprise architecture activity and maturity, as well as in the advancement of the use of enterprise architecture to guide political decisions on IT investments. In addition to providing the methods for the assessment, EAAF also identifies the measurement areas and criteria by which government agencies are to rely on the architecture to drive performance improvements. This is integrated into the so-called Performance Improvement Lifecycle, where points for improvement are identified and translated into specific actions.&lt;br /&gt;
&lt;br /&gt;
In that sense, the framework provides a good overall methodology for the assessment of DE4A BB. Following its guidelines, in order to perform the technical assessment, the architects, together with the relevant project partners (mainly from WP1 and WP4):&lt;br /&gt;
&lt;br /&gt;
* Identify and prioritize the BB considering the pilots’ needs and in view of the project goals and objectives;&lt;br /&gt;
* Determine specific methodological steps for gap analysis, using common or shared information assets and information technology assets;&lt;br /&gt;
* Quantify/qualify and assess the performance to verify compliance with pilots’ requirements and provide report on gap closure; and&lt;br /&gt;
* Assess feedback on the pilots’ performance in order to enhance the architecture and fine-tune the assessment methodology for future implementation decisions.&lt;br /&gt;
&lt;br /&gt;
=== Methodological considerations ===&lt;br /&gt;
The need to develop a generic methodology that integrates some aspects of the standardized methodologies, but does not rely on a single one, is based on several considerations: &lt;br /&gt;
&lt;br /&gt;
# The assessment methodologies currently available either focus on alignment of the BB specifications or are only concerned with the maturity of the solution provided by the building blocks; &lt;br /&gt;
# They do not provide a clear definition of the common principles for assessment;&lt;br /&gt;
# They do not allow for a phased-approach to the assessment and are applicable either for a single BB or for a finalized solution architecture (Note: Although EAAF prescribes the principles for a phased assessment, it does not delineate the phases explicitly and only gives a requirement for the overall outcome of the assessment). &lt;br /&gt;
&lt;br /&gt;
As a result, the architect is prevented from developing an assessment for multiple BB with varying levels of complexity and is also disabled to perform comparative evaluation for determining the best fit for a particular solution architecture. &lt;br /&gt;
&lt;br /&gt;
The methodology developed here is novel in that it addresses the points above and is also generic in the sense that it can be reused by other large-scale projects for similar purposes. It incorporates the assessment principles of existing standards-based methodologies (like CAMSS and EAAF) taking into account the architecture feasibility and sustainability, but it also generalizes these principles over the context of implementation required by DE4A.&lt;br /&gt;
&lt;br /&gt;
== Methodology ==&lt;br /&gt;
In order to account for both the piloting recommendations criteria and the performance assessment criteria, the overall methodology requires a phased approach. Therefore, it consists of two phases:&lt;br /&gt;
&lt;br /&gt;
I) The first phase takes stock of the entire list of BB that can have potential use in the project and as part of the piloting. Then, a conceptual and an empirical framework for evaluation is developed – the former enables the gap analysis of the BB, whereas the latter allows for qualitative and comparative analysis of the BB, as well as extraction of concrete recommendations for piloting. The first phase essentially corresponds to the first three points of the EAAF.&lt;br /&gt;
&lt;br /&gt;
II) The second phase will account for the complete list of project artefacts and will provide empirical validation for the results and recommendations from the first phase. In addition, reassessment of the previous gaps will be performed. This phase will mainly be realized in close collaboration with the pilots: direct feedback via surveys and questionnaires on BB performance will be obtained and the initial conceptual framework will be fine-tuned accordingly. The second phase corresponds to the last point of the EAAF.&lt;br /&gt;
&lt;br /&gt;
=== Conceptual framework ===&lt;br /&gt;
In this section, we first catalogue the BB that are to be considered by the assessment. This step considers the output from D1.5 and establishes a relation to the internal project environment. Then we establish a common conceptualization of the key elements, which is based on the Digital service model, Section 2.2 of the Study on &amp;quot;The feasibility and scenarios for the long-term sustainability of the Large Scale Pilots”. With that, a relation to the external project environment is established. Finally, a basic assessment framework is developed to enable the grading of the BB from several maturity aspects: technical, administrative and operational. The output of the assessment will allow us to perform gap analysis and will also guide the extraction of the piloting recommendations.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''The Digital Services Model: A five-layered approach'''&lt;br /&gt;
&lt;br /&gt;
The LSPs so far have developed building blocks that enable cross-border interoperability based on standards, specifications and common code/components. Therefore, moving beyond the pilot projects and towards actual deployment, it is crucial to develop a structure in which the digital services and the elements they are composed of can be conceptualized.&lt;br /&gt;
&lt;br /&gt;
To establish a conceptual model, it is important to clearly set out the key terminology that is used in relation to the DSI for the provision of cross-border public services. CEF provides an overarching framework suitable for this purpose, called Digital Services Model (DSM). It takes into account the deliverables of the LSPs, the stakeholders and roles they can take on, and the drivers behind the dynamics of this complex ecosystem.&lt;br /&gt;
&lt;br /&gt;
The Digital Services Model is not only needed to establish common terminology and framework, but it is also necessary to analyse the needs and requirements for the future deployment of any digital services, enabling a continuity of the developed methodologies with the LSPs. Thus, it presents the different levels of granularity which need to be taken into consideration for the overall management of the DSI for the provision of public Services.&lt;br /&gt;
&lt;br /&gt;
The following elements represent the main part of the DSM taxonomy:&lt;br /&gt;
&lt;br /&gt;
# Standards and Specifications;&lt;br /&gt;
# Common code or Components;&lt;br /&gt;
# Building Blocks;&lt;br /&gt;
# Core Service Platforms;&lt;br /&gt;
# Generic Services.&lt;br /&gt;
&lt;br /&gt;
Standards and Specifications have been used by all the LSPs for the development of the digital services. These standards and specifications play a central role in interoperability as it means that systems have commonalities in key areas, enabling systems to communicate with one another.&lt;br /&gt;
&lt;br /&gt;
Components are the common code that has been developed for the building blocks. Building blocks are made up of several components (e.g. a timestamp component/functionality). These are often referred to as modules in the deliverables of the LSPs. Component can either be BB-specific or used in several BB.&lt;br /&gt;
&lt;br /&gt;
Essentially, all the solutions derived from the LSPs are ultimately building blocks in the sense that they are services that can be integrated as part of other services. Given the fact that these building blocks have the most obvious potential for reuse across different domains (or Core Service Platforms) these can be seen as a specific layer as part of the set of digital services.&lt;br /&gt;
&lt;br /&gt;
Core Service Platforms enable the provision of cross-border digital services in different domains, like eHealth, eJustice and eProcurement. These are the platforms where all the different BB for a specific service (e.g. eHealth services or eID services) are brought together and made available, enabling service providers to take up and reuse the services as part of their own services. The Core Service Platform (CSP) level should eventually enable the Member States to interact with other Member States through the use of building blocks (via the Generic Services).&lt;br /&gt;
&lt;br /&gt;
It is important to determine what building blocks have been developed by an LSP, as well as which of these are CSP-specific and which are reusable. The CSP-specific blocks are called domain blocks (e.g. ePrescription is specific to eHealth) and the reusable blocks are called building blocks (e.g. eID can be reused in various domains).&lt;br /&gt;
&lt;br /&gt;
The reusable building blocks are the strongest common element between the various CSPs. They therefore need to meet the needs and requirements of all the CSPs. This underlines the links between the building blocks and the CSPs, and the need to manage both of these simultaneously.&lt;br /&gt;
&lt;br /&gt;
Generic Services is the level of abstraction at which the Member States integrate or connect to the CSPs. These interconnections are necessary to link up a Member State so it can provide cross-border access and use of national eIDs, electronic health records, national procurement platforms, national eJustice platforms and public services for foreign business. Each Member State has to ensure that these existing systems at national level are linked up with the CSPs through Generic Services in order to be cross-border enabled.&lt;br /&gt;
&lt;br /&gt;
To define a common taxonomy for BB description prior to the actual assessment, the relevant BB are catalogued in view of the five-layered model described above. This is represented in the figure below (Taxonomy of Building Blocks). &lt;br /&gt;
[[File:Taxonomy of Building Blocks.png|alt=Taxonomy of Building Blocks|Taxonomy of Building Blocks|center|frame]]Although implicitly understandable, it is worth noting that some BB can belong to two different categories, as their application is largely context dependent. In other words, whereas in one context a certain BB can be seen as a Standard/Specification, in another context it can be a Component. In those cases, the more general category is assigned to that BB, giving priority to show its potential rather than its most common use. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Assessment criteria'''&lt;br /&gt;
&lt;br /&gt;
In this section, a basic assessment framework is presented composed of the criteria that guide the expert scoring of BB from the aspect of technical, administrative and operational maturity. The criteria essentially represent a matrix indexed by two dimensions: Score and Maturity aspect. These dimensions, together with the semantics of the criteria (the matrix-cells) are shown in the table below (Conceptual BB assessment framework). For better graphical representation of the empirical assessment that will be performed in the next section, each row is represented by a colour, visually grasping the overall maturity of a certain building block.&lt;br /&gt;
[[File:Conceptual BB assessment framework.png|alt=Conceptual BB assessment framework|center|thumb|600x600px|Conceptual BB assessment framework]]&lt;br /&gt;
The colouring of the framework is not important only for the visual appeal of the reader; rather, it is meant to serve as a concrete input (an additional dimension) for the prospective formalization of the assessment framework. Such formalization would enable a semi- and, ultimately, a fully automatic maturity and quality attributes assessment of both a set of desired (composable) BB, as well as a solution architecture representing a Common Service Platform or a General Service per se. &lt;br /&gt;
&lt;br /&gt;
It is important to note that the framework represented above is a simplified version of the generic assessment framework that will be the final contribution by WP2. This is because at this stage it cannot be expected that all necessary information by the pilots is obtained for an overall architecture evaluation to take place. Such assessment will be performed in the second phase of the ''BB assessment'' task, when the framework from Table 2 will also be further revised and fine-tuned. As a result, the gap analysis in the second phase will take into account the exhaustive set of pilots’ requirements and the pilots’ feedback on the implemented BB.&lt;br /&gt;
&lt;br /&gt;
=== Empirical framework ===&lt;br /&gt;
The empirical framework is essentially an implementation of the conceptual framework with concrete recommendations as an output. While the conceptual framework is based on well-standardized assessment methodologies, the (input to the) empirical evaluation of the BB relies largely on expert opinions and judgements. To close the subjectivity gap between the experts’ evaluation criteria, the BB Assessment group defined an internal process of iterative calibration on the evaluation criteria, as represented by the process flow below:&lt;br /&gt;
[[File:Calibration process for BB evaluation criteria.png|alt=Calibration process for BB evaluation criteria|center|thumb|600x600px|Calibration process for BB evaluation criteria]]&lt;br /&gt;
In the '''Preparatory step''', the building blocks were matched to the experts’ experience and expertise with respect to the capabilities provided by each BB and the architecture principles outlined by the DE4A objectives. One or more groups of BB with shared capabilities were then assigned to each expert for assessment.  &lt;br /&gt;
&lt;br /&gt;
In the '''Assessment step''', the initial evaluation criteria were agreed upon and integrated into the [https://wiki.de4a.eu/index.php/File:Conceptual_BB_assessment_framework.png basic assessment framework]. Then, the results from the initial assessments for each BB were presented in front of the BB Assessment group. This allowed for a constructive discussion on the need to fine-tune the evaluation criteria and to revise the evaluation results. These considerations are part of the '''Fine-tuning step''', which is essentially an iterative procedure on its own, until the complete set of evaluation criteria is obtained, and the BB scores are approved by all experts of the BB Assessment group.&lt;br /&gt;
&lt;br /&gt;
In the '''Recommendation step''', the final scores for each BB were provided for all three maturity aspects: Technical, Administrative and Operational. These are then analysed in view of the piloting requirements and the DE4A objectives as part of the Gap analysis, enabling the extraction of a single Recommendation as an output from the overall process.&lt;br /&gt;
&lt;br /&gt;
The output of the preparatory step is the Taxonomy of BB, whereas the output of the Assessment step is the conceptual framework – further whose criteria, aspects and semantics were fine-tuned in the third step. The scores and recommendations are obtained as an output from the final (Recommendation) step, supported by the argumentation given in the Gap Analysis. For a more complete overview of the final scores and recommendation, they are succinctly represented altogether in the BB recommendations table below. &lt;br /&gt;
&lt;br /&gt;
=== Recommendations and Gap Analysis ===&lt;br /&gt;
This section summarizes the assessment for each building block, by aspect and with an overall recommendation grade. A recommendation is essentially the expert opinion based on the results from the conceptual framework, the gap analysis and in relation to the piloting needs and requirements. The overall list of assessed BB is catalogued as follows:&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|+BB recommendations&lt;br /&gt;
|'''#'''&lt;br /&gt;
|'''Building Block'''&lt;br /&gt;
|'''Technical Maturity'''&lt;br /&gt;
|'''Administrative Maturity'''&lt;br /&gt;
|'''Operational Maturity'''&lt;br /&gt;
|'''Recommendation'''&lt;br /&gt;
|-&lt;br /&gt;
|1&lt;br /&gt;
|eDelivery&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Implemented  and running&lt;br /&gt;
|Completely  aligned with current EU policies &lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | runs  in production in EU (one or more MS) &lt;br /&gt;
|Recommended&lt;br /&gt;
|-&lt;br /&gt;
|2&lt;br /&gt;
|eID&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Implemented  and running&lt;br /&gt;
|Completely  aligned with current EU policies &lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | runs  in production in EU (one or more MS) &lt;br /&gt;
|Recommended&lt;br /&gt;
|-&lt;br /&gt;
|3&lt;br /&gt;
|eSignature&lt;br /&gt;
|Cutting-edge &lt;br /&gt;
|Completely  aligned with current EU policies &lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | runs  in production in EU (one or more MS) &lt;br /&gt;
|Recommended&lt;br /&gt;
|-&lt;br /&gt;
|4&lt;br /&gt;
|CCCEV&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Implemented  and running&lt;br /&gt;
|Completely  aligned with current EU policies &lt;br /&gt;
|Piloted &lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Acceptable&lt;br /&gt;
|-&lt;br /&gt;
|5&lt;br /&gt;
|CPSV-AP&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Implemented  and running&lt;br /&gt;
|Completely  aligned with current EU policies &lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | runs  in production in EU (one or more MS) &lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Acceptable&lt;br /&gt;
|-&lt;br /&gt;
|6&lt;br /&gt;
|eCertis&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Implemented  and running&lt;br /&gt;
|Completely  aligned with current EU policies &lt;br /&gt;
|EU  infrastructure, broadly accepted &lt;br /&gt;
|Recommended&lt;br /&gt;
|-&lt;br /&gt;
|7&lt;br /&gt;
|eIDAS interoperability  specifications&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Implemented  and running&lt;br /&gt;
|Completely  aligned with current EU policies &lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | runs  in production in EU (one or more MS) &lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Acceptable&lt;br /&gt;
|-&lt;br /&gt;
|8&lt;br /&gt;
|sTESTA&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Implemented  and running&lt;br /&gt;
|Completely  aligned with current EU policies &lt;br /&gt;
|EU  infrastructure, broadly accepted &lt;br /&gt;
|Discarded&lt;br /&gt;
|-&lt;br /&gt;
|9&lt;br /&gt;
|x-Road&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Implemented  and running&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Aligned  with national policies, but is yet to be aligned with the EU&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | runs  in production in EU (one or more MS) &lt;br /&gt;
|Useful&lt;br /&gt;
|-&lt;br /&gt;
|10&lt;br /&gt;
|DCAT-AP&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Implemented  and running&lt;br /&gt;
|Completely  aligned with current EU policies &lt;br /&gt;
|EU  infrastructure, broadly accepted &lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Acceptable&lt;br /&gt;
|-&lt;br /&gt;
|11&lt;br /&gt;
|BREG-DCAT-AP &lt;br /&gt;
|Not  stable/ under development &lt;br /&gt;
|Acceptable,  but subject to improvement&lt;br /&gt;
|Piloted&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Acceptable&lt;br /&gt;
|-&lt;br /&gt;
|12&lt;br /&gt;
|ISA2 Multilingual Forms&lt;br /&gt;
|Implemented and running&lt;br /&gt;
|Completely aligned with  current EU policies &lt;br /&gt;
|runs in production in EU  (one or more MS) &lt;br /&gt;
|Acceptable&lt;br /&gt;
|-&lt;br /&gt;
|13&lt;br /&gt;
|EBSI (CEF Blockchain)&lt;br /&gt;
|Not  stable/ under development &lt;br /&gt;
|Acceptable,  but subject to improvement&lt;br /&gt;
|Piloted &lt;br /&gt;
|Useful&lt;br /&gt;
|-&lt;br /&gt;
|14&lt;br /&gt;
|eInvoicing&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Implemented  and running&lt;br /&gt;
|Completely  aligned with current EU policies &lt;br /&gt;
|EU  infrastructure, broadly accepted &lt;br /&gt;
|Recommended&lt;br /&gt;
|-&lt;br /&gt;
|15&lt;br /&gt;
|eTranslation&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Implemented  and running&lt;br /&gt;
|Completely  aligned with current EU policies &lt;br /&gt;
|EU  infrastructure, broadly accepted &lt;br /&gt;
|Recommended&lt;br /&gt;
|-&lt;br /&gt;
|16&lt;br /&gt;
|SEMPER&lt;br /&gt;
|Not  stable/ under development &lt;br /&gt;
|Acceptable,  but subject to improvement&lt;br /&gt;
|Piloted&lt;br /&gt;
|Recommended&lt;br /&gt;
|-&lt;br /&gt;
|17&lt;br /&gt;
|BRIS&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Implemented  and running&lt;br /&gt;
|Completely  aligned with current EU policies &lt;br /&gt;
|EU  infrastructure, broadly accepted &lt;br /&gt;
|Discarded&lt;br /&gt;
|-&lt;br /&gt;
|18&lt;br /&gt;
|TOOP Architecture&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Implemented and running&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Aligned with national  policies, but is yet to be aligned with the EU&lt;br /&gt;
|Piloted &lt;br /&gt;
|Recommended&lt;br /&gt;
|-&lt;br /&gt;
|19&lt;br /&gt;
|TOOP CERB&lt;br /&gt;
|Not stable/ under  development &lt;br /&gt;
|Acceptable, but subject  to improvement&lt;br /&gt;
|Piloted &lt;br /&gt;
|Useful&lt;br /&gt;
|-&lt;br /&gt;
|20&lt;br /&gt;
|TOOP DSD&lt;br /&gt;
|Not stable/ under  development &lt;br /&gt;
|Acceptable, but subject  to improvement&lt;br /&gt;
|Piloted &lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Acceptable &lt;br /&gt;
|-&lt;br /&gt;
|21&lt;br /&gt;
|TOOP eDelivery [SMP/SML and BDXL]&lt;br /&gt;
|Cutting-edge &lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Aligned with national  policies, but is yet to be aligned with the EU&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | runs in production in EU  (one or more MS) &lt;br /&gt;
|Recommended&lt;br /&gt;
|-&lt;br /&gt;
|22&lt;br /&gt;
|TOOP EDM&lt;br /&gt;
|Not stable/ under development &lt;br /&gt;
|Acceptable, but subject  to improvement&lt;br /&gt;
|Concept &lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Acceptable&lt;br /&gt;
|-&lt;br /&gt;
|23&lt;br /&gt;
|TOOP TC&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Implemented and running&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Aligned with national  policies, but is yet to be aligned with the EU&lt;br /&gt;
|Piloted &lt;br /&gt;
|Recommended&lt;br /&gt;
|-&lt;br /&gt;
|24&lt;br /&gt;
|TOOP Gateway&lt;br /&gt;
|Cutting-edge &lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Aligned with national  policies, but is yet to be aligned with the EU&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | runs in production in EU  (one or more MS) &lt;br /&gt;
|Recommended&lt;br /&gt;
|-&lt;br /&gt;
|25&lt;br /&gt;
|TOOP Testing Tool&lt;br /&gt;
|Not stable/ under  development &lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Acceptable, but subject  to improvement&lt;br /&gt;
|Piloted &lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Acceptable&lt;br /&gt;
|-&lt;br /&gt;
|26&lt;br /&gt;
|ADMS-AP&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Implemented  and running&lt;br /&gt;
|Completely  aligned with current EU policies &lt;br /&gt;
|EU  infrastructure, broadly accepted &lt;br /&gt;
|Useful&lt;br /&gt;
|-&lt;br /&gt;
|27&lt;br /&gt;
|EDCI&lt;br /&gt;
|Not  stable/ under development &lt;br /&gt;
|Acceptable,  but subject to improvement&lt;br /&gt;
|Piloted&lt;br /&gt;
|&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Useful&lt;br /&gt;
|-&lt;br /&gt;
|28&lt;br /&gt;
|EES&lt;br /&gt;
|Not  stable/ under development &lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Aligned  with national policies, yet to be aligned with the EU&lt;br /&gt;
|Concept&lt;br /&gt;
|Useful&lt;br /&gt;
|-&lt;br /&gt;
|29&lt;br /&gt;
|eTimeStamp&lt;br /&gt;
|Not  stable/ under development &lt;br /&gt;
|Completely  aligned with current EU policies &lt;br /&gt;
|Concept&lt;br /&gt;
|Recommended&lt;br /&gt;
|-&lt;br /&gt;
|30&lt;br /&gt;
|eDocument&lt;br /&gt;
|Not  stable/ under development &lt;br /&gt;
|Acceptable,  but subject to improvement&lt;br /&gt;
|Concept &lt;br /&gt;
|Discarded&lt;br /&gt;
|-&lt;br /&gt;
|31&lt;br /&gt;
|RPAM&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Implemented  and running&lt;br /&gt;
|Acceptable,  but subject to improvement&lt;br /&gt;
|Piloted &lt;br /&gt;
|Useful&lt;br /&gt;
|-&lt;br /&gt;
|32&lt;br /&gt;
|SMP/SML&lt;br /&gt;
|Cutting-edge &lt;br /&gt;
|Completely  aligned with current EU policies &lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | runs in production in EU  (one or more MS) &lt;br /&gt;
|Recommended&lt;br /&gt;
|-&lt;br /&gt;
|33&lt;br /&gt;
|IMI&lt;br /&gt;
|Cutting-edge &lt;br /&gt;
|Completely  aligned with current EU policies &lt;br /&gt;
|EU  infrastructure, broadly accepted &lt;br /&gt;
|Discarded&lt;br /&gt;
|}&lt;br /&gt;
Following is the analysis of the results from the overall assessment from the aspect of the pilots’ needs, the conceptual framework and the overall architectural principles. It is important to note that this is not the exhaustive set of gap analysis, but it serves as a proof of concept for the methodological and assessment choices decisions made. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Pilots needs’ considerations'''&lt;br /&gt;
&lt;br /&gt;
From the table above, it can be noted that, although some of the BB are assessed as immature from some aspect, the final recommendation is still for them to be used by the pilots. This is due to the fact that, regardless of the current state of maturity, when matched with the pilots’ requirements, some a BB may still have the necessary architecture capabilities that require adjustment in the DE4A context. For instance, this is the case with SEMPER. The SEMPER extension to eIDAS is not fully mature yet but is the only cross-border functionality for working with proxies that currently mandates successfully piloted. Otherwise, there will be a need to develop a DE4A-specific solution for cross-border powers validation from the scratch, which is bot not useful and not feasible within the project timeframe. In order for SEMPER to gain a broader user-base, it has to be validated by more Member States (currently, it has been piloted with 4 MS). In addition, SEMPER has been piloted with legal persons only. Although this is sufficient to the DBA pilot, this is not the case for the moving abroad and studying abroad, as there is a need for piloting with natural persons. The DE4A pilots themselves may be used for this. Finally, SEMPER extends eIDAS, but has not been handed over to DIGIT yet. Therefore, it has not been incorporated in the eIDAS reference software of DIGIT yet. Integration in eIDAS will improve sustainability of the SEMPER extension. Concretely, SEMPER would benefit from eIDAS-like specifications to allow Member States that do not use the eIDAS reference software to develop their own extension based on these specifications. &lt;br /&gt;
&lt;br /&gt;
In contrast to SEMPER, there is also a case where a BB may be assessed as completely mature in most of the aspects but is still disregarded at the Recommendations stage. This is, for instance, the case with the IMI BB, which despite the overall high maturity in all aspects is out of the scope of the DE4A project. Similarly, the BRIS building block has a scope that is much narrower (especially from an administrative perspective) than the scope of DE4A and is therefore not to be used by the pilots. More concretely, BRIS has been developed for inter-business register communication, which is not the primary focus of the DBA pilot (the functional shortcomings on BRIS for piloting in DBA (D4.5, annex V) have been confirmed by DG DIGIT and there is no BRIS-roadmap foreseen that will deliver a solution to the findings). Furthermore, it is legally not feasible to use the BRIS-network for the DE4A-pilots (currently not allowed for non-business registers). An alternative is being discussed with DIGIT: a message broking platform as a possible future BRIS-wide solution that is piloted in TOOP. However, funding for continuation of the platform is not arranged and the current intention is to bring the (cloud-based) prototype infrastructure down when TOOP testing ends.&lt;br /&gt;
&lt;br /&gt;
Similar reasoning in compiling the overall recommendation score is applied to the other building blocks. These considerations have been discussed in detail at the BB Assessment Group meetings during the Recommendation step of the empirical framework. It is out of scope of the deliverable to present a detailed overview of each BB. However, the subtlety of some of the assessment criteria (such as context dependence) is also an argument to justify the decision to rely only on the experts’ evaluations in the first phase of the methodology.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Assessment outcomes considerations'''&lt;br /&gt;
&lt;br /&gt;
Out of the 33 assessed BB, 13 BB are Recommended for implementation, 9 are Acceptable, 7 are Useful and 4 are Discarded. From a maturity point of view: in terms of technical maturity, 5 are cutting-edge, 18 are implemented and running in an operational environment, whereas 10 are not stable or under development. From an administrative maturity aspect, almost half (17) of the BB are completely aligned with current EU policies; 7 are aligned with national policies but are yet to be consolidated at an EU level, whereas 9 (although acceptable) are still subject to further improvements. &lt;br /&gt;
[[File:Taxonomy of assessed BB with their recommendations .png|alt=Taxonomy of assessed BBs with their recommendations |center|frame|Taxonomy of assessed BB with their recommendations ]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
From operational maturity aspect, there are 8 BB which are broadly accepted as part of an EU infrastructure, 12 that run in production in one or more Member States and 10 that are piloted within some kind of operational or testing environment. It is interesting to note that the only aspect by which a BB has been assessed as immature is the Operational aspect. Thus, there are 4 BB (TOOD EDM, EES, eTimeStamp and eDocument) that are marked as operationally immature, as they are only at the stage of a Concept and are yet to be developed.&lt;br /&gt;
&lt;br /&gt;
From a BB type aspect (also visible in the figure above), most of the recommended BB are of the type ‘Building Block’ (7 out of 13) and ‘Standards and specifications’, whereas the ‘General services’ and the ‘Core service platforms’ are the least numerous and the most immature. This is expected, as the later are also the most complex ones and only few in number across EU. &lt;br /&gt;
&lt;br /&gt;
It is also notable that most of the BB considered for use by the pilots are in a mature and useful state that allows reusability and potential upgrades before implementation in the DE4A pilots. Such considerations are already being made (as discussed in the previous subsection) and are part of the piloting requirements to be assessed in the second phase of the methodology. &lt;br /&gt;
&lt;br /&gt;
'''Architecture framework considerations'''&lt;br /&gt;
&lt;br /&gt;
As outlined in the methodological considerations above, the two phases of the overall methodology follow the Enterprise Architecture Assessment Framework principles, with the additional step of providing recommendations for the pilot in between the two phases. Such an approach allows, in addition to the qualitative evaluation, to obtain e quantitative score for the maturity of the overall architecture as a (sub)set of the assessed BB. In that sense, while the output of the EAAF is a maturity level assessment of the overall architecture, the phased approach in DE4A creates an intermediate feedback loop between the pilots and the Project Start Architecture, allowing for adaptable integration of the assessment methodology within the WP2 change management.&lt;br /&gt;
&lt;br /&gt;
Regardless of the incomplete overall assessment, it is still possible to have a quantitative assessment for a solution architecture after the first assessment phase. However, this is not to be considered as the overall architecture framework maturity level, but only as a ‘current maturity level’ of the solution architecture comprised of a given set of BB. Such value can serve as a reference point to be compared upon a given KPI for the overall maturity, in case there is such requirement.&lt;br /&gt;
&lt;br /&gt;
In order to compile a single value for the current maturity level for a pilot solution architecture, the set of BB assessments and their recommendations shall be compared upon the baseline for the EAAF maturity levels.&lt;br /&gt;
[[File:EAAF Maturity levels.png|alt=EAAF Maturity levels|center|frame|EAAF Maturity levels]]&lt;br /&gt;
In the context of DE4A, we will provide such assessment in the second phase of implementation of this methodology, as currently there is no definite list of BB matched to the specific pilots.&lt;/div&gt;</summary>
		<author><name>Ictu mavi.cristache</name></author>
	</entry>
	<entry>
		<id>https://wiki.de4a.eu/index.php?title=Building_Blocks&amp;diff=3001</id>
		<title>Building Blocks</title>
		<link rel="alternate" type="text/html" href="https://wiki.de4a.eu/index.php?title=Building_Blocks&amp;diff=3001"/>
		<updated>2021-07-15T16:28:17Z</updated>

		<summary type="html">&lt;p&gt;Ictu mavi.cristache: /* Recommendations and Gap Analysis */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The purpose of the Building Blocks (BB) assessment is to assess the suitability of the BB identified and catalogued in Task 1.5 for use within the DE4A project. Thus, it bridges outputs from WP1 and requirements from WP4 to provide input for the technical, operational and administrative considerations in the architectural assessments carried out here. Over 40 BB have been considered for this assessment, 31 of which are assessed at the first phase of this work. The results of the assessment show that there is a mature and acceptable stock of solution building blocks that can be considered as potential candidates for implementation by the pilots, either in their entirety or partially, with the needed upgrades.&lt;br /&gt;
&lt;br /&gt;
== Theoretical background ==&lt;br /&gt;
&lt;br /&gt;
=== Objectives and scope ===&lt;br /&gt;
To reach the goal outlined above, this section delves into the architectural evaluation of the building blocks catalogued as useful for DE4A. It is important to note that the term “building block” in the context of this assessment refers to a Solution Building Block in TOGAF sense. &lt;br /&gt;
&lt;br /&gt;
The most important step in assessing the BB is determining the methodology that would support a common description framework of the BB, while providing means for determining the quantitative and/or qualitative evaluation criteria of the considered BB. The outcome of the assessment is a succinct list of recommendations for BB use by the pilots in WP4. In addition to defining the methodology, a gap analysis is performed based on both the pilots’ requirements and the common description framework of the BB, considering the results from the assessment, the project requirements and the common PSA principles. The overall process of conceptual considerations, empirical evaluation, gap analysis and piloting recommendations are denoted as a DE4A generic methodology for architecture building blocks evaluation.&lt;br /&gt;
&lt;br /&gt;
=== Available methodologies ===&lt;br /&gt;
In order to provide continuity and justification of the methodology that is being developed, we first outline and assess the suitability of the currently available methodologies in view of the implementation context and the objectives of the DE4A project. To that end, both generic EU/EC assessment methodologies and past LSP project-specific methodologies are considered.&lt;br /&gt;
&lt;br /&gt;
==== Common assessment method for standards and specifications (CAMSS) ====&lt;br /&gt;
[https://ec.europa.eu/isa2/solutions/camss_en CAMSS] is part of the ISA² interoperability solutions evaluation toolkit for public administrations, businesses and citizens. It provides a method to assist in the assessment of ICT standards and specifications. The main objective of CAMSS is achieving interoperability and avoiding vendor lock-in. In that sense, CAMSS criteria evaluate (among other things) the openness of standards and specifications. This is done by employing the CAMSS tools and adapting the evaluation according to the needs of an individual Member State.&lt;br /&gt;
&lt;br /&gt;
In the context of DE4A, relying solely on CAMSS does not provide the means for BB suitability and gap analysis in relation to the piloting needs. Moreover, it does not provide any selection criteria or a taxonomy for consistent mapping of the different BB onto a common comparable framework.&lt;br /&gt;
&lt;br /&gt;
==== Past project-specific methodologies ====&lt;br /&gt;
'''eSENS'''&lt;br /&gt;
&lt;br /&gt;
eSENS has developed its own methodology for BB assessment, which is mainly an adaptation of CAMSS and Asset Description Metadata Schema (ADMS), supported by inputs of the [https://web.archive.org/web/20200928232327/http://www.esens.eu/deliverables eSENS deliverable D6.1] (see Table 5 in [https://web.archive.org/web/20200928232327/http://www.esens.eu/deliverables eSENS D3.1]). Its objective is to propose a documentation of format and defining criteria for the maturity and sustainability assessment of building blocks. The overall framework consists of three steps: 1) The Consideration step; 2) The Assessment step; and 3) The Recommendation step and produces a list of assessment criteria to be used for BB evaluation. These criteria, however, are very general and not architecture-specific – their applicability is valid and valuable only if used in collaboration with the legal, business, organizational, technical and implementation team.&lt;br /&gt;
&lt;br /&gt;
It is important to note that the assessment methodology employed in eSENS is developed with a different aim from ours – its analysis and recommendations refer to the desired BB qualities that are needed to ensure meeting the maturity levels and the sustainability criteria envisaged by the project. Thus, although it produces guidelines for assessment, it does not provide concrete output in terms of actual scores, analysis and recommendations for BB. Moreover, it does not provide a comparable baseline when multiple BB have to be considered for the same pilot and it is based on the assumption that the existing BB represent the exhaustive list of possible solutions from which a suitable match should be chosen. In the case of DE4A, such an assumption does not hold, as there may be a case where a certain BB is not mature enough to be recommended for piloting but is also not to be completely disregarded either. More importantly, the methodology developed here is used for actual assessment and is to be fine-tuned at a later stage in connection to the general architecture lifecycle development.&lt;br /&gt;
&lt;br /&gt;
'''TOOP'''&lt;br /&gt;
&lt;br /&gt;
Like eSENS, the overall idea of the TOOP assessment methodology is to reuse existing frameworks and building blocks provided by CEF, eSENS, and other initiatives. First, an initial inventory of existing e- Government building blocks is proposed. Then, the principles of selection of building blocks for OOP applications are provided, together with high-level views of the architecture. Finally, an analysis of selected building blocks is done with respect to their relevance, applicability, sustainability, need for further development and external interfaces.&lt;br /&gt;
&lt;br /&gt;
The main criteria for inclusion of a building block in TOOP are:&lt;br /&gt;
&lt;br /&gt;
* The specific project requirements;&lt;br /&gt;
* The TOOP pilots’ needs;&lt;br /&gt;
* Usability in long-term applications (maintenance and support provided).&lt;br /&gt;
&lt;br /&gt;
As a result, the building blocks are categorized into three basic groups:&lt;br /&gt;
&lt;br /&gt;
# BB that provide capabilities needed by all or most TOOP Pilot Areas;&lt;br /&gt;
# BB that provide capabilities needed or probably needed by some TOOP Pilot Areas;&lt;br /&gt;
# BB that provide capabilities not needed by the TOOP Pilot Areas.&lt;br /&gt;
&lt;br /&gt;
TOOP’s criteria are tightly bound to the piloting needs, whereas the rationale behind their choice is OOP-specific rather than generic. The methodology here follows a similar line of reasoning, but differs in the conceptual framework, which is more formally defined and made reusable by other projects as well. &lt;br /&gt;
&lt;br /&gt;
==== ISA2 Interim Evaluation ====&lt;br /&gt;
The [https://ec.europa.eu/isa2/sites/isa/files/190613_synopsis_report.pdf interim evaluation] aimed to assess how well the ISA² Programme has performed since its start in 2016 and whether its existence continues to be justified. Based on stakeholders’ views, opinions and public consultation, it evaluated the implementation of the programme based on seven criteria and identified several points for improvement. &lt;br /&gt;
&lt;br /&gt;
The evaluation criteria considered were: Relevance (the alignment between the objectives of the programme and the current needs and problems experienced by stakeholders); Effectiveness (the extent to which the programme has achieved its objectives); Efficiency (the extent to which the programme’s objectives are achieved at a minimum cost); Coherence (the alignment between the programme and comparable EU initiatives as well as the overall EU policy framework); EU added value (the additional impacts generated by the programme, as opposed to leaving the subject matter in the hands of Member States); Utility (the extent to which the programme meets stakeholders’ needs); and Sustainability (the likelihood that the programme’s results will last beyond its completion).&lt;br /&gt;
&lt;br /&gt;
However, the interim evaluation does not provide a specific methodology – either in terms of criteria choice, or in terms of architectural or future piloting recommendations. Its value lies mainly in the identification of possible gaps that exist within the current EU architecture framework even prior to the implementation of the available building blocks. In that sense, the main recommendations for prospective actions are determined in awareness raising beyond national administrations; moving from user-centric to user-driven solutions; and working towards increased sustainability.&lt;br /&gt;
&lt;br /&gt;
Our work integrates the interim evaluation criteria even at the stage of cataloguing BB relevant in DE4A context. More importantly, it takes into consideration the methodological gaps identified in the assessment in terms of awareness, user-driven solutions and sustainability prescriptions and integrates specific technical, administrative and operational aspects in the recommendation’s extraction for the pilots. &lt;br /&gt;
&lt;br /&gt;
==== EAAF ====&lt;br /&gt;
The [https://obamawhitehouse.archives.gov/sites/default/files/omb/assets/fea_docs/OMB_EA_Assessment_Framework_v3_1_June_2009.pdf Enterprise Architecture Assessment Framework (EAAF)] assists the US government in the assessment and reporting of their enterprise architecture activity and maturity, as well as in the advancement of the use of enterprise architecture to guide political decisions on IT investments. In addition to providing the methods for the assessment, EAAF also identifies the measurement areas and criteria by which government agencies are to rely on the architecture to drive performance improvements. This is integrated into the so-called Performance Improvement Lifecycle, where points for improvement are identified and translated into specific actions.&lt;br /&gt;
&lt;br /&gt;
In that sense, the framework provides a good overall methodology for the assessment of DE4A BB. Following its guidelines, in order to perform the technical assessment, the architects, together with the relevant project partners (mainly from WP1 and WP4):&lt;br /&gt;
&lt;br /&gt;
* Identify and prioritize the BB considering the pilots’ needs and in view of the project goals and objectives;&lt;br /&gt;
* Determine specific methodological steps for gap analysis, using common or shared information assets and information technology assets;&lt;br /&gt;
* Quantify/qualify and assess the performance to verify compliance with pilots’ requirements and provide report on gap closure; and&lt;br /&gt;
* Assess feedback on the pilots’ performance in order to enhance the architecture and fine-tune the assessment methodology for future implementation decisions.&lt;br /&gt;
&lt;br /&gt;
=== Methodological considerations ===&lt;br /&gt;
The need to develop a generic methodology that integrates some aspects of the standardized methodologies, but does not rely on a single one, is based on several considerations: &lt;br /&gt;
&lt;br /&gt;
# The assessment methodologies currently available either focus on alignment of the BB specifications or are only concerned with the maturity of the solution provided by the building blocks; &lt;br /&gt;
# They do not provide a clear definition of the common principles for assessment;&lt;br /&gt;
# They do not allow for a phased-approach to the assessment and are applicable either for a single BB or for a finalized solution architecture (Note: Although EAAF prescribes the principles for a phased assessment, it does not delineate the phases explicitly and only gives a requirement for the overall outcome of the assessment). &lt;br /&gt;
&lt;br /&gt;
As a result, the architect is prevented from developing an assessment for multiple BB with varying levels of complexity and is also disabled to perform comparative evaluation for determining the best fit for a particular solution architecture. &lt;br /&gt;
&lt;br /&gt;
The methodology developed here is novel in that it addresses the points above and is also generic in the sense that it can be reused by other large-scale projects for similar purposes. It incorporates the assessment principles of existing standards-based methodologies (like CAMSS and EAAF) taking into account the architecture feasibility and sustainability, but it also generalizes these principles over the context of implementation required by DE4A.&lt;br /&gt;
&lt;br /&gt;
== Methodology ==&lt;br /&gt;
In order to account for both the piloting recommendations criteria and the performance assessment criteria, the overall methodology requires a phased approach. Therefore, it consists of two phases:&lt;br /&gt;
&lt;br /&gt;
I) The first phase takes stock of the entire list of BB that can have potential use in the project and as part of the piloting. Then, a conceptual and an empirical framework for evaluation is developed – the former enables the gap analysis of the BB, whereas the latter allows for qualitative and comparative analysis of the BB, as well as extraction of concrete recommendations for piloting. The first phase essentially corresponds to the first three points of the EAAF.&lt;br /&gt;
&lt;br /&gt;
II) The second phase will account for the complete list of project artefacts and will provide empirical validation for the results and recommendations from the first phase. In addition, reassessment of the previous gaps will be performed. This phase will mainly be realized in close collaboration with the pilots: direct feedback via surveys and questionnaires on BB performance will be obtained and the initial conceptual framework will be fine-tuned accordingly. The second phase corresponds to the last point of the EAAF.&lt;br /&gt;
&lt;br /&gt;
=== Conceptual framework ===&lt;br /&gt;
In this section, we first catalogue the BB that are to be considered by the assessment. This step considers the output from D1.5 and establishes a relation to the internal project environment. Then we establish a common conceptualization of the key elements, which is based on the Digital service model, Section 2.2 of the Study on &amp;quot;The feasibility and scenarios for the long-term sustainability of the Large Scale Pilots”. With that, a relation to the external project environment is established. Finally, a basic assessment framework is developed to enable the grading of the BB from several maturity aspects: technical, administrative and operational. The output of the assessment will allow us to perform gap analysis and will also guide the extraction of the piloting recommendations.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''The Digital Services Model: A five-layered approach'''&lt;br /&gt;
&lt;br /&gt;
The LSPs so far have developed building blocks that enable cross-border interoperability based on standards, specifications and common code/components. Therefore, moving beyond the pilot projects and towards actual deployment, it is crucial to develop a structure in which the digital services and the elements they are composed of can be conceptualized.&lt;br /&gt;
&lt;br /&gt;
To establish a conceptual model, it is important to clearly set out the key terminology that is used in relation to the DSI for the provision of cross-border public services. CEF provides an overarching framework suitable for this purpose, called Digital Services Model (DSM). It takes into account the deliverables of the LSPs, the stakeholders and roles they can take on, and the drivers behind the dynamics of this complex ecosystem.&lt;br /&gt;
&lt;br /&gt;
The Digital Services Model is not only needed to establish common terminology and framework, but it is also necessary to analyse the needs and requirements for the future deployment of any digital services, enabling a continuity of the developed methodologies with the LSPs. Thus, it presents the different levels of granularity which need to be taken into consideration for the overall management of the DSI for the provision of public Services.&lt;br /&gt;
&lt;br /&gt;
The following elements represent the main part of the DSM taxonomy:&lt;br /&gt;
&lt;br /&gt;
# Standards and Specifications;&lt;br /&gt;
# Common code or Components;&lt;br /&gt;
# Building Blocks;&lt;br /&gt;
# Core Service Platforms;&lt;br /&gt;
# Generic Services.&lt;br /&gt;
&lt;br /&gt;
Standards and Specifications have been used by all the LSPs for the development of the digital services. These standards and specifications play a central role in interoperability as it means that systems have commonalities in key areas, enabling systems to communicate with one another.&lt;br /&gt;
&lt;br /&gt;
Components are the common code that has been developed for the building blocks. Building blocks are made up of several components (e.g. a timestamp component/functionality). These are often referred to as modules in the deliverables of the LSPs. Component can either be BB-specific or used in several BB.&lt;br /&gt;
&lt;br /&gt;
Essentially, all the solutions derived from the LSPs are ultimately building blocks in the sense that they are services that can be integrated as part of other services. Given the fact that these building blocks have the most obvious potential for reuse across different domains (or Core Service Platforms) these can be seen as a specific layer as part of the set of digital services.&lt;br /&gt;
&lt;br /&gt;
Core Service Platforms enable the provision of cross-border digital services in different domains, like eHealth, eJustice and eProcurement. These are the platforms where all the different BB for a specific service (e.g. eHealth services or eID services) are brought together and made available, enabling service providers to take up and reuse the services as part of their own services. The Core Service Platform (CSP) level should eventually enable the Member States to interact with other Member States through the use of building blocks (via the Generic Services).&lt;br /&gt;
&lt;br /&gt;
It is important to determine what building blocks have been developed by an LSP, as well as which of these are CSP-specific and which are reusable. The CSP-specific blocks are called domain blocks (e.g. ePrescription is specific to eHealth) and the reusable blocks are called building blocks (e.g. eID can be reused in various domains).&lt;br /&gt;
&lt;br /&gt;
The reusable building blocks are the strongest common element between the various CSPs. They therefore need to meet the needs and requirements of all the CSPs. This underlines the links between the building blocks and the CSPs, and the need to manage both of these simultaneously.&lt;br /&gt;
&lt;br /&gt;
Generic Services is the level of abstraction at which the Member States integrate or connect to the CSPs. These interconnections are necessary to link up a Member State so it can provide cross-border access and use of national eIDs, electronic health records, national procurement platforms, national eJustice platforms and public services for foreign business. Each Member State has to ensure that these existing systems at national level are linked up with the CSPs through Generic Services in order to be cross-border enabled.&lt;br /&gt;
&lt;br /&gt;
To define a common taxonomy for BB description prior to the actual assessment, the relevant BB are catalogued in view of the five-layered model described above. This is represented in the figure below (Taxonomy of Building Blocks). &lt;br /&gt;
[[File:Taxonomy of Building Blocks.png|alt=Taxonomy of Building Blocks|Taxonomy of Building Blocks|center|frame]]Although implicitly understandable, it is worth noting that some BB can belong to two different categories, as their application is largely context dependent. In other words, whereas in one context a certain BB can be seen as a Standard/Specification, in another context it can be a Component. In those cases, the more general category is assigned to that BB, giving priority to show its potential rather than its most common use. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Assessment criteria'''&lt;br /&gt;
&lt;br /&gt;
In this section, a basic assessment framework is presented composed of the criteria that guide the expert scoring of BB from the aspect of technical, administrative and operational maturity. The criteria essentially represent a matrix indexed by two dimensions: Score and Maturity aspect. These dimensions, together with the semantics of the criteria (the matrix-cells) are shown in the table below (Conceptual BB assessment framework). For better graphical representation of the empirical assessment that will be performed in the next section, each row is represented by a colour, visually grasping the overall maturity of a certain building block.&lt;br /&gt;
[[File:Conceptual BB assessment framework.png|alt=Conceptual BB assessment framework|center|thumb|600x600px|Conceptual BB assessment framework]]&lt;br /&gt;
The colouring of the framework is not important only for the visual appeal of the reader; rather, it is meant to serve as a concrete input (an additional dimension) for the prospective formalization of the assessment framework. Such formalization would enable a semi- and, ultimately, a fully automatic maturity and quality attributes assessment of both a set of desired (composable) BB, as well as a solution architecture representing a Common Service Platform or a General Service per se. &lt;br /&gt;
&lt;br /&gt;
It is important to note that the framework represented above is a simplified version of the generic assessment framework that will be the final contribution by WP2. This is because at this stage it cannot be expected that all necessary information by the pilots is obtained for an overall architecture evaluation to take place. Such assessment will be performed in the second phase of the ''BB assessment'' task, when the framework from Table 2 will also be further revised and fine-tuned. As a result, the gap analysis in the second phase will take into account the exhaustive set of pilots’ requirements and the pilots’ feedback on the implemented BB.&lt;br /&gt;
&lt;br /&gt;
=== Empirical framework ===&lt;br /&gt;
The empirical framework is essentially an implementation of the conceptual framework with concrete recommendations as an output. While the conceptual framework is based on well-standardized assessment methodologies, the (input to the) empirical evaluation of the BB relies largely on expert opinions and judgements. To close the subjectivity gap between the experts’ evaluation criteria, the BB Assessment group defined an internal process of iterative calibration on the evaluation criteria, as represented by the process flow below:&lt;br /&gt;
[[File:Calibration process for BB evaluation criteria.png|alt=Calibration process for BB evaluation criteria|center|thumb|600x600px|Calibration process for BB evaluation criteria]]&lt;br /&gt;
In the '''Preparatory step''', the building blocks were matched to the experts’ experience and expertise with respect to the capabilities provided by each BB and the architecture principles outlined by the DE4A objectives. One or more groups of BB with shared capabilities were then assigned to each expert for assessment.  &lt;br /&gt;
&lt;br /&gt;
In the '''Assessment step''', the initial evaluation criteria were agreed upon and integrated into the [https://wiki.de4a.eu/index.php/File:Conceptual_BB_assessment_framework.png basic assessment framework]. Then, the results from the initial assessments for each BB were presented in front of the BB Assessment group. This allowed for a constructive discussion on the need to fine-tune the evaluation criteria and to revise the evaluation results. These considerations are part of the '''Fine-tuning step''', which is essentially an iterative procedure on its own, until the complete set of evaluation criteria is obtained, and the BB scores are approved by all experts of the BB Assessment group.&lt;br /&gt;
&lt;br /&gt;
In the '''Recommendation step''', the final scores for each BB were provided for all three maturity aspects: Technical, Administrative and Operational. These are then analysed in view of the piloting requirements and the DE4A objectives as part of the Gap analysis, enabling the extraction of a single Recommendation as an output from the overall process.&lt;br /&gt;
&lt;br /&gt;
The output of the preparatory step is the Taxonomy of BB, whereas the output of the Assessment step is the conceptual framework – further whose criteria, aspects and semantics were fine-tuned in the third step. The scores and recommendations are obtained as an output from the final (Recommendation) step, supported by the argumentation given in the Gap Analysis. For a more complete overview of the final scores and recommendation, they are succinctly represented altogether in the BB recommendations table below. &lt;br /&gt;
&lt;br /&gt;
=== Recommendations and Gap Analysis ===&lt;br /&gt;
This section summarizes the assessment for each building block, by aspect and with an overall recommendation grade. A recommendation is essentially the expert opinion based on the results from the conceptual framework, the gap analysis and in relation to the piloting needs and requirements. The overall list of assessed BB is catalogued as follows:&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|+BB recommendations&lt;br /&gt;
|'''#'''&lt;br /&gt;
|'''Building Block'''&lt;br /&gt;
|'''Technical Maturity'''&lt;br /&gt;
|'''Administrative Maturity'''&lt;br /&gt;
|'''Operational Maturity'''&lt;br /&gt;
|'''Recommendation'''&lt;br /&gt;
|-&lt;br /&gt;
|1&lt;br /&gt;
|eDelivery&lt;br /&gt;
| style=&amp;quot;background-color:#92D050;&amp;quot; | Implemented  and running&lt;br /&gt;
|Completely  aligned with current EU policies &lt;br /&gt;
|runs  in production in EU (one or more MS) &lt;br /&gt;
|Recommended&lt;br /&gt;
|-&lt;br /&gt;
|2&lt;br /&gt;
|eID&lt;br /&gt;
|Implemented  and running&lt;br /&gt;
|Completely  aligned with current EU policies &lt;br /&gt;
|runs  in production in EU (one or more MS) &lt;br /&gt;
|Recommended&lt;br /&gt;
|-&lt;br /&gt;
|3&lt;br /&gt;
|eSignature&lt;br /&gt;
|Cutting-edge &lt;br /&gt;
|Completely  aligned with current EU policies &lt;br /&gt;
|runs  in production in EU (one or more MS) &lt;br /&gt;
|Recommended&lt;br /&gt;
|-&lt;br /&gt;
|4&lt;br /&gt;
|CCCEV&lt;br /&gt;
|Implemented  and running&lt;br /&gt;
|Completely  aligned with current EU policies &lt;br /&gt;
|Piloted &lt;br /&gt;
|Acceptable&lt;br /&gt;
|-&lt;br /&gt;
|5&lt;br /&gt;
|CPSV-AP&lt;br /&gt;
|Implemented  and running&lt;br /&gt;
|Completely  aligned with current EU policies &lt;br /&gt;
|runs  in production in EU (one or more MS) &lt;br /&gt;
|Acceptable&lt;br /&gt;
|-&lt;br /&gt;
|6&lt;br /&gt;
|eCertis&lt;br /&gt;
|Implemented  and running&lt;br /&gt;
|Completely  aligned with current EU policies &lt;br /&gt;
|EU  infrastructure, broadly accepted &lt;br /&gt;
|Recommended&lt;br /&gt;
|-&lt;br /&gt;
|7&lt;br /&gt;
|eIDAS interoperability  specifications&lt;br /&gt;
|Implemented  and running&lt;br /&gt;
|Completely  aligned with current EU policies &lt;br /&gt;
|runs  in production in EU (one or more MS) &lt;br /&gt;
|Acceptable&lt;br /&gt;
|-&lt;br /&gt;
|8&lt;br /&gt;
|sTESTA&lt;br /&gt;
|Implemented  and running&lt;br /&gt;
|Completely  aligned with current EU policies &lt;br /&gt;
|EU  infrastructure, broadly accepted &lt;br /&gt;
|Discarded&lt;br /&gt;
|-&lt;br /&gt;
|9&lt;br /&gt;
|x-Road&lt;br /&gt;
|Implemented  and running&lt;br /&gt;
|Aligned  with national policies, but is yet to be aligned with the EU&lt;br /&gt;
|runs  in production in EU (one or more MS) &lt;br /&gt;
|Useful&lt;br /&gt;
|-&lt;br /&gt;
|10&lt;br /&gt;
|DCAT-AP&lt;br /&gt;
|Implemented  and running&lt;br /&gt;
|Completely  aligned with current EU policies &lt;br /&gt;
|EU  infrastructure, broadly accepted &lt;br /&gt;
|Acceptable&lt;br /&gt;
|-&lt;br /&gt;
|11&lt;br /&gt;
|BREG-DCAT-AP &lt;br /&gt;
|Not  stable/ under development &lt;br /&gt;
|Acceptable,  but subject to improvement&lt;br /&gt;
|Piloted&lt;br /&gt;
|Acceptable&lt;br /&gt;
|-&lt;br /&gt;
|12&lt;br /&gt;
|ISA2 Multilingual Forms&lt;br /&gt;
|Implemented and running&lt;br /&gt;
|Completely aligned with  current EU policies &lt;br /&gt;
|runs in production in EU  (one or more MS) &lt;br /&gt;
|Acceptable&lt;br /&gt;
|-&lt;br /&gt;
|13&lt;br /&gt;
|EBSI (CEF Blockchain)&lt;br /&gt;
|Not  stable/ under development &lt;br /&gt;
|Acceptable,  but subject to improvement&lt;br /&gt;
|Piloted &lt;br /&gt;
|Useful&lt;br /&gt;
|-&lt;br /&gt;
|14&lt;br /&gt;
|eInvoicing&lt;br /&gt;
|Implemented  and running&lt;br /&gt;
|Completely  aligned with current EU policies &lt;br /&gt;
|EU  infrastructure, broadly accepted &lt;br /&gt;
|Recommended&lt;br /&gt;
|-&lt;br /&gt;
|15&lt;br /&gt;
|eTranslation&lt;br /&gt;
|Implemented  and running&lt;br /&gt;
|Completely  aligned with current EU policies &lt;br /&gt;
|EU  infrastructure, broadly accepted &lt;br /&gt;
|Recommended&lt;br /&gt;
|-&lt;br /&gt;
|16&lt;br /&gt;
|SEMPER&lt;br /&gt;
|Not  stable/ under development &lt;br /&gt;
|Acceptable,  but subject to improvement&lt;br /&gt;
|Piloted&lt;br /&gt;
|Recommended&lt;br /&gt;
|-&lt;br /&gt;
|17&lt;br /&gt;
|BRIS&lt;br /&gt;
|Implemented  and running&lt;br /&gt;
|Completely  aligned with current EU policies &lt;br /&gt;
|EU  infrastructure, broadly accepted &lt;br /&gt;
|Discarded&lt;br /&gt;
|-&lt;br /&gt;
|18&lt;br /&gt;
|TOOP Architecture&lt;br /&gt;
|Implemented and running&lt;br /&gt;
|Aligned with national  policies, but is yet to be aligned with the EU&lt;br /&gt;
|Piloted &lt;br /&gt;
|Recommended&lt;br /&gt;
|-&lt;br /&gt;
|19&lt;br /&gt;
|TOOP CERB&lt;br /&gt;
|Not stable/ under  development &lt;br /&gt;
|Acceptable, but subject  to improvement&lt;br /&gt;
|Piloted &lt;br /&gt;
|Useful&lt;br /&gt;
|-&lt;br /&gt;
|20&lt;br /&gt;
|TOOP DSD&lt;br /&gt;
|Not stable/ under  development &lt;br /&gt;
|Acceptable, but subject  to improvement&lt;br /&gt;
|Piloted &lt;br /&gt;
|Acceptable &lt;br /&gt;
|-&lt;br /&gt;
|21&lt;br /&gt;
|TOOP eDelivery [SMP/SML and BDXL]&lt;br /&gt;
|Cutting-edge &lt;br /&gt;
|Aligned with national  policies, but is yet to be aligned with the EU&lt;br /&gt;
|runs in production in EU  (one or more MS) &lt;br /&gt;
|Recommended&lt;br /&gt;
|-&lt;br /&gt;
|22&lt;br /&gt;
|TOOP EDM&lt;br /&gt;
|Not stable/ under development &lt;br /&gt;
|Acceptable, but subject  to improvement&lt;br /&gt;
|Concept &lt;br /&gt;
|Acceptable&lt;br /&gt;
|-&lt;br /&gt;
|23&lt;br /&gt;
|TOOP TC&lt;br /&gt;
|Implemented and running&lt;br /&gt;
|Aligned with national  policies, but is yet to be aligned with the EU&lt;br /&gt;
|Piloted &lt;br /&gt;
|Recommended&lt;br /&gt;
|-&lt;br /&gt;
|24&lt;br /&gt;
|TOOP Gateway&lt;br /&gt;
|Cutting-edge &lt;br /&gt;
|Aligned with national  policies, but is yet to be aligned with the EU&lt;br /&gt;
|runs in production in EU  (one or more MS) &lt;br /&gt;
|Recommended&lt;br /&gt;
|-&lt;br /&gt;
|25&lt;br /&gt;
|TOOP Testing Tool&lt;br /&gt;
|Not stable/ under  development &lt;br /&gt;
|Acceptable, but subject  to improvement&lt;br /&gt;
|Piloted &lt;br /&gt;
|Acceptable&lt;br /&gt;
|-&lt;br /&gt;
|26&lt;br /&gt;
|ADMS-AP&lt;br /&gt;
|Implemented  and running&lt;br /&gt;
|Completely  aligned with current EU policies &lt;br /&gt;
|EU  infrastructure, broadly accepted &lt;br /&gt;
|Useful&lt;br /&gt;
|-&lt;br /&gt;
|27&lt;br /&gt;
|EDCI&lt;br /&gt;
|Not  stable/ under development &lt;br /&gt;
|Acceptable,  but subject to improvement&lt;br /&gt;
|Piloted&lt;br /&gt;
|&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Useful&lt;br /&gt;
|-&lt;br /&gt;
|28&lt;br /&gt;
|EES&lt;br /&gt;
|Not  stable/ under development &lt;br /&gt;
|Aligned  with national policies, yet to be aligned with the EU&lt;br /&gt;
|Concept&lt;br /&gt;
|Useful&lt;br /&gt;
|-&lt;br /&gt;
|29&lt;br /&gt;
|eTimeStamp&lt;br /&gt;
|Not  stable/ under development &lt;br /&gt;
|Completely  aligned with current EU policies &lt;br /&gt;
|Concept&lt;br /&gt;
|Recommended&lt;br /&gt;
|-&lt;br /&gt;
|30&lt;br /&gt;
|eDocument&lt;br /&gt;
|Not  stable/ under development &lt;br /&gt;
|Acceptable,  but subject to improvement&lt;br /&gt;
|Concept &lt;br /&gt;
|Discarded&lt;br /&gt;
|-&lt;br /&gt;
|31&lt;br /&gt;
|RPAM&lt;br /&gt;
|Implemented  and running&lt;br /&gt;
|Acceptable,  but subject to improvement&lt;br /&gt;
|Piloted &lt;br /&gt;
|Useful&lt;br /&gt;
|-&lt;br /&gt;
|32&lt;br /&gt;
|SMP/SML&lt;br /&gt;
|Cutting-edge &lt;br /&gt;
|Completely  aligned with current EU policies &lt;br /&gt;
|runs in production in EU  (one or more MS) &lt;br /&gt;
|Recommended&lt;br /&gt;
|-&lt;br /&gt;
|33&lt;br /&gt;
|IMI&lt;br /&gt;
|Cutting-edge &lt;br /&gt;
|Completely  aligned with current EU policies &lt;br /&gt;
|EU  infrastructure, broadly accepted &lt;br /&gt;
|Discarded&lt;br /&gt;
|}&lt;br /&gt;
Following is the analysis of the results from the overall assessment from the aspect of the pilots’ needs, the conceptual framework and the overall architectural principles. It is important to note that this is not the exhaustive set of gap analysis, but it serves as a proof of concept for the methodological and assessment choices decisions made. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Pilots needs’ considerations'''&lt;br /&gt;
&lt;br /&gt;
From the table above, it can be noted that, although some of the BB are assessed as immature from some aspect, the final recommendation is still for them to be used by the pilots. This is due to the fact that, regardless of the current state of maturity, when matched with the pilots’ requirements, some a BB may still have the necessary architecture capabilities that require adjustment in the DE4A context. For instance, this is the case with SEMPER. The SEMPER extension to eIDAS is not fully mature yet but is the only cross-border functionality for working with proxies that currently mandates successfully piloted. Otherwise, there will be a need to develop a DE4A-specific solution for cross-border powers validation from the scratch, which is bot not useful and not feasible within the project timeframe. In order for SEMPER to gain a broader user-base, it has to be validated by more Member States (currently, it has been piloted with 4 MS). In addition, SEMPER has been piloted with legal persons only. Although this is sufficient to the DBA pilot, this is not the case for the moving abroad and studying abroad, as there is a need for piloting with natural persons. The DE4A pilots themselves may be used for this. Finally, SEMPER extends eIDAS, but has not been handed over to DIGIT yet. Therefore, it has not been incorporated in the eIDAS reference software of DIGIT yet. Integration in eIDAS will improve sustainability of the SEMPER extension. Concretely, SEMPER would benefit from eIDAS-like specifications to allow Member States that do not use the eIDAS reference software to develop their own extension based on these specifications. &lt;br /&gt;
&lt;br /&gt;
In contrast to SEMPER, there is also a case where a BB may be assessed as completely mature in most of the aspects but is still disregarded at the Recommendations stage. This is, for instance, the case with the IMI BB, which despite the overall high maturity in all aspects is out of the scope of the DE4A project. Similarly, the BRIS building block has a scope that is much narrower (especially from an administrative perspective) than the scope of DE4A and is therefore not to be used by the pilots. More concretely, BRIS has been developed for inter-business register communication, which is not the primary focus of the DBA pilot (the functional shortcomings on BRIS for piloting in DBA (D4.5, annex V) have been confirmed by DG DIGIT and there is no BRIS-roadmap foreseen that will deliver a solution to the findings). Furthermore, it is legally not feasible to use the BRIS-network for the DE4A-pilots (currently not allowed for non-business registers). An alternative is being discussed with DIGIT: a message broking platform as a possible future BRIS-wide solution that is piloted in TOOP. However, funding for continuation of the platform is not arranged and the current intention is to bring the (cloud-based) prototype infrastructure down when TOOP testing ends.&lt;br /&gt;
&lt;br /&gt;
Similar reasoning in compiling the overall recommendation score is applied to the other building blocks. These considerations have been discussed in detail at the BB Assessment Group meetings during the Recommendation step of the empirical framework. It is out of scope of the deliverable to present a detailed overview of each BB. However, the subtlety of some of the assessment criteria (such as context dependence) is also an argument to justify the decision to rely only on the experts’ evaluations in the first phase of the methodology.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Assessment outcomes considerations'''&lt;br /&gt;
&lt;br /&gt;
Out of the 33 assessed BB, 13 BB are Recommended for implementation, 9 are Acceptable, 7 are Useful and 4 are Discarded. From a maturity point of view: in terms of technical maturity, 5 are cutting-edge, 18 are implemented and running in an operational environment, whereas 10 are not stable or under development. From an administrative maturity aspect, almost half (17) of the BB are completely aligned with current EU policies; 7 are aligned with national policies but are yet to be consolidated at an EU level, whereas 9 (although acceptable) are still subject to further improvements. &lt;br /&gt;
[[File:Taxonomy of assessed BB with their recommendations .png|alt=Taxonomy of assessed BBs with their recommendations |center|frame|Taxonomy of assessed BB with their recommendations ]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
From operational maturity aspect, there are 8 BB which are broadly accepted as part of an EU infrastructure, 12 that run in production in one or more Member States and 10 that are piloted within some kind of operational or testing environment. It is interesting to note that the only aspect by which a BB has been assessed as immature is the Operational aspect. Thus, there are 4 BB (TOOD EDM, EES, eTimeStamp and eDocument) that are marked as operationally immature, as they are only at the stage of a Concept and are yet to be developed.&lt;br /&gt;
&lt;br /&gt;
From a BB type aspect (also visible in the figure above), most of the recommended BB are of the type ‘Building Block’ (7 out of 13) and ‘Standards and specifications’, whereas the ‘General services’ and the ‘Core service platforms’ are the least numerous and the most immature. This is expected, as the later are also the most complex ones and only few in number across EU. &lt;br /&gt;
&lt;br /&gt;
It is also notable that most of the BB considered for use by the pilots are in a mature and useful state that allows reusability and potential upgrades before implementation in the DE4A pilots. Such considerations are already being made (as discussed in the previous subsection) and are part of the piloting requirements to be assessed in the second phase of the methodology. &lt;br /&gt;
&lt;br /&gt;
'''Architecture framework considerations'''&lt;br /&gt;
&lt;br /&gt;
As outlined in the methodological considerations above, the two phases of the overall methodology follow the Enterprise Architecture Assessment Framework principles, with the additional step of providing recommendations for the pilot in between the two phases. Such an approach allows, in addition to the qualitative evaluation, to obtain e quantitative score for the maturity of the overall architecture as a (sub)set of the assessed BB. In that sense, while the output of the EAAF is a maturity level assessment of the overall architecture, the phased approach in DE4A creates an intermediate feedback loop between the pilots and the Project Start Architecture, allowing for adaptable integration of the assessment methodology within the WP2 change management.&lt;br /&gt;
&lt;br /&gt;
Regardless of the incomplete overall assessment, it is still possible to have a quantitative assessment for a solution architecture after the first assessment phase. However, this is not to be considered as the overall architecture framework maturity level, but only as a ‘current maturity level’ of the solution architecture comprised of a given set of BB. Such value can serve as a reference point to be compared upon a given KPI for the overall maturity, in case there is such requirement.&lt;br /&gt;
&lt;br /&gt;
In order to compile a single value for the current maturity level for a pilot solution architecture, the set of BB assessments and their recommendations shall be compared upon the baseline for the EAAF maturity levels.&lt;br /&gt;
[[File:EAAF Maturity levels.png|alt=EAAF Maturity levels|center|frame|EAAF Maturity levels]]&lt;br /&gt;
In the context of DE4A, we will provide such assessment in the second phase of implementation of this methodology, as currently there is no definite list of BB matched to the specific pilots.&lt;/div&gt;</summary>
		<author><name>Ictu mavi.cristache</name></author>
	</entry>
	<entry>
		<id>https://wiki.de4a.eu/index.php?title=Building_Blocks&amp;diff=3000</id>
		<title>Building Blocks</title>
		<link rel="alternate" type="text/html" href="https://wiki.de4a.eu/index.php?title=Building_Blocks&amp;diff=3000"/>
		<updated>2021-07-15T16:24:48Z</updated>

		<summary type="html">&lt;p&gt;Ictu mavi.cristache: /* Assessment criteria */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The purpose of the Building Blocks (BB) assessment is to assess the suitability of the BB identified and catalogued in Task 1.5 for use within the DE4A project. Thus, it bridges outputs from WP1 and requirements from WP4 to provide input for the technical, operational and administrative considerations in the architectural assessments carried out here. Over 40 BB have been considered for this assessment, 31 of which are assessed at the first phase of this work. The results of the assessment show that there is a mature and acceptable stock of solution building blocks that can be considered as potential candidates for implementation by the pilots, either in their entirety or partially, with the needed upgrades.&lt;br /&gt;
&lt;br /&gt;
== Theoretical background ==&lt;br /&gt;
&lt;br /&gt;
=== Objectives and scope ===&lt;br /&gt;
To reach the goal outlined above, this section delves into the architectural evaluation of the building blocks catalogued as useful for DE4A. It is important to note that the term “building block” in the context of this assessment refers to a Solution Building Block in TOGAF sense. &lt;br /&gt;
&lt;br /&gt;
The most important step in assessing the BB is determining the methodology that would support a common description framework of the BB, while providing means for determining the quantitative and/or qualitative evaluation criteria of the considered BB. The outcome of the assessment is a succinct list of recommendations for BB use by the pilots in WP4. In addition to defining the methodology, a gap analysis is performed based on both the pilots’ requirements and the common description framework of the BB, considering the results from the assessment, the project requirements and the common PSA principles. The overall process of conceptual considerations, empirical evaluation, gap analysis and piloting recommendations are denoted as a DE4A generic methodology for architecture building blocks evaluation.&lt;br /&gt;
&lt;br /&gt;
=== Available methodologies ===&lt;br /&gt;
In order to provide continuity and justification of the methodology that is being developed, we first outline and assess the suitability of the currently available methodologies in view of the implementation context and the objectives of the DE4A project. To that end, both generic EU/EC assessment methodologies and past LSP project-specific methodologies are considered.&lt;br /&gt;
&lt;br /&gt;
==== Common assessment method for standards and specifications (CAMSS) ====&lt;br /&gt;
[https://ec.europa.eu/isa2/solutions/camss_en CAMSS] is part of the ISA² interoperability solutions evaluation toolkit for public administrations, businesses and citizens. It provides a method to assist in the assessment of ICT standards and specifications. The main objective of CAMSS is achieving interoperability and avoiding vendor lock-in. In that sense, CAMSS criteria evaluate (among other things) the openness of standards and specifications. This is done by employing the CAMSS tools and adapting the evaluation according to the needs of an individual Member State.&lt;br /&gt;
&lt;br /&gt;
In the context of DE4A, relying solely on CAMSS does not provide the means for BB suitability and gap analysis in relation to the piloting needs. Moreover, it does not provide any selection criteria or a taxonomy for consistent mapping of the different BB onto a common comparable framework.&lt;br /&gt;
&lt;br /&gt;
==== Past project-specific methodologies ====&lt;br /&gt;
'''eSENS'''&lt;br /&gt;
&lt;br /&gt;
eSENS has developed its own methodology for BB assessment, which is mainly an adaptation of CAMSS and Asset Description Metadata Schema (ADMS), supported by inputs of the [https://web.archive.org/web/20200928232327/http://www.esens.eu/deliverables eSENS deliverable D6.1] (see Table 5 in [https://web.archive.org/web/20200928232327/http://www.esens.eu/deliverables eSENS D3.1]). Its objective is to propose a documentation of format and defining criteria for the maturity and sustainability assessment of building blocks. The overall framework consists of three steps: 1) The Consideration step; 2) The Assessment step; and 3) The Recommendation step and produces a list of assessment criteria to be used for BB evaluation. These criteria, however, are very general and not architecture-specific – their applicability is valid and valuable only if used in collaboration with the legal, business, organizational, technical and implementation team.&lt;br /&gt;
&lt;br /&gt;
It is important to note that the assessment methodology employed in eSENS is developed with a different aim from ours – its analysis and recommendations refer to the desired BB qualities that are needed to ensure meeting the maturity levels and the sustainability criteria envisaged by the project. Thus, although it produces guidelines for assessment, it does not provide concrete output in terms of actual scores, analysis and recommendations for BB. Moreover, it does not provide a comparable baseline when multiple BB have to be considered for the same pilot and it is based on the assumption that the existing BB represent the exhaustive list of possible solutions from which a suitable match should be chosen. In the case of DE4A, such an assumption does not hold, as there may be a case where a certain BB is not mature enough to be recommended for piloting but is also not to be completely disregarded either. More importantly, the methodology developed here is used for actual assessment and is to be fine-tuned at a later stage in connection to the general architecture lifecycle development.&lt;br /&gt;
&lt;br /&gt;
'''TOOP'''&lt;br /&gt;
&lt;br /&gt;
Like eSENS, the overall idea of the TOOP assessment methodology is to reuse existing frameworks and building blocks provided by CEF, eSENS, and other initiatives. First, an initial inventory of existing e- Government building blocks is proposed. Then, the principles of selection of building blocks for OOP applications are provided, together with high-level views of the architecture. Finally, an analysis of selected building blocks is done with respect to their relevance, applicability, sustainability, need for further development and external interfaces.&lt;br /&gt;
&lt;br /&gt;
The main criteria for inclusion of a building block in TOOP are:&lt;br /&gt;
&lt;br /&gt;
* The specific project requirements;&lt;br /&gt;
* The TOOP pilots’ needs;&lt;br /&gt;
* Usability in long-term applications (maintenance and support provided).&lt;br /&gt;
&lt;br /&gt;
As a result, the building blocks are categorized into three basic groups:&lt;br /&gt;
&lt;br /&gt;
# BB that provide capabilities needed by all or most TOOP Pilot Areas;&lt;br /&gt;
# BB that provide capabilities needed or probably needed by some TOOP Pilot Areas;&lt;br /&gt;
# BB that provide capabilities not needed by the TOOP Pilot Areas.&lt;br /&gt;
&lt;br /&gt;
TOOP’s criteria are tightly bound to the piloting needs, whereas the rationale behind their choice is OOP-specific rather than generic. The methodology here follows a similar line of reasoning, but differs in the conceptual framework, which is more formally defined and made reusable by other projects as well. &lt;br /&gt;
&lt;br /&gt;
==== ISA2 Interim Evaluation ====&lt;br /&gt;
The [https://ec.europa.eu/isa2/sites/isa/files/190613_synopsis_report.pdf interim evaluation] aimed to assess how well the ISA² Programme has performed since its start in 2016 and whether its existence continues to be justified. Based on stakeholders’ views, opinions and public consultation, it evaluated the implementation of the programme based on seven criteria and identified several points for improvement. &lt;br /&gt;
&lt;br /&gt;
The evaluation criteria considered were: Relevance (the alignment between the objectives of the programme and the current needs and problems experienced by stakeholders); Effectiveness (the extent to which the programme has achieved its objectives); Efficiency (the extent to which the programme’s objectives are achieved at a minimum cost); Coherence (the alignment between the programme and comparable EU initiatives as well as the overall EU policy framework); EU added value (the additional impacts generated by the programme, as opposed to leaving the subject matter in the hands of Member States); Utility (the extent to which the programme meets stakeholders’ needs); and Sustainability (the likelihood that the programme’s results will last beyond its completion).&lt;br /&gt;
&lt;br /&gt;
However, the interim evaluation does not provide a specific methodology – either in terms of criteria choice, or in terms of architectural or future piloting recommendations. Its value lies mainly in the identification of possible gaps that exist within the current EU architecture framework even prior to the implementation of the available building blocks. In that sense, the main recommendations for prospective actions are determined in awareness raising beyond national administrations; moving from user-centric to user-driven solutions; and working towards increased sustainability.&lt;br /&gt;
&lt;br /&gt;
Our work integrates the interim evaluation criteria even at the stage of cataloguing BB relevant in DE4A context. More importantly, it takes into consideration the methodological gaps identified in the assessment in terms of awareness, user-driven solutions and sustainability prescriptions and integrates specific technical, administrative and operational aspects in the recommendation’s extraction for the pilots. &lt;br /&gt;
&lt;br /&gt;
==== EAAF ====&lt;br /&gt;
The [https://obamawhitehouse.archives.gov/sites/default/files/omb/assets/fea_docs/OMB_EA_Assessment_Framework_v3_1_June_2009.pdf Enterprise Architecture Assessment Framework (EAAF)] assists the US government in the assessment and reporting of their enterprise architecture activity and maturity, as well as in the advancement of the use of enterprise architecture to guide political decisions on IT investments. In addition to providing the methods for the assessment, EAAF also identifies the measurement areas and criteria by which government agencies are to rely on the architecture to drive performance improvements. This is integrated into the so-called Performance Improvement Lifecycle, where points for improvement are identified and translated into specific actions.&lt;br /&gt;
&lt;br /&gt;
In that sense, the framework provides a good overall methodology for the assessment of DE4A BB. Following its guidelines, in order to perform the technical assessment, the architects, together with the relevant project partners (mainly from WP1 and WP4):&lt;br /&gt;
&lt;br /&gt;
* Identify and prioritize the BB considering the pilots’ needs and in view of the project goals and objectives;&lt;br /&gt;
* Determine specific methodological steps for gap analysis, using common or shared information assets and information technology assets;&lt;br /&gt;
* Quantify/qualify and assess the performance to verify compliance with pilots’ requirements and provide report on gap closure; and&lt;br /&gt;
* Assess feedback on the pilots’ performance in order to enhance the architecture and fine-tune the assessment methodology for future implementation decisions.&lt;br /&gt;
&lt;br /&gt;
=== Methodological considerations ===&lt;br /&gt;
The need to develop a generic methodology that integrates some aspects of the standardized methodologies, but does not rely on a single one, is based on several considerations: &lt;br /&gt;
&lt;br /&gt;
# The assessment methodologies currently available either focus on alignment of the BB specifications or are only concerned with the maturity of the solution provided by the building blocks; &lt;br /&gt;
# They do not provide a clear definition of the common principles for assessment;&lt;br /&gt;
# They do not allow for a phased-approach to the assessment and are applicable either for a single BB or for a finalized solution architecture (Note: Although EAAF prescribes the principles for a phased assessment, it does not delineate the phases explicitly and only gives a requirement for the overall outcome of the assessment). &lt;br /&gt;
&lt;br /&gt;
As a result, the architect is prevented from developing an assessment for multiple BB with varying levels of complexity and is also disabled to perform comparative evaluation for determining the best fit for a particular solution architecture. &lt;br /&gt;
&lt;br /&gt;
The methodology developed here is novel in that it addresses the points above and is also generic in the sense that it can be reused by other large-scale projects for similar purposes. It incorporates the assessment principles of existing standards-based methodologies (like CAMSS and EAAF) taking into account the architecture feasibility and sustainability, but it also generalizes these principles over the context of implementation required by DE4A.&lt;br /&gt;
&lt;br /&gt;
== Methodology ==&lt;br /&gt;
In order to account for both the piloting recommendations criteria and the performance assessment criteria, the overall methodology requires a phased approach. Therefore, it consists of two phases:&lt;br /&gt;
&lt;br /&gt;
I) The first phase takes stock of the entire list of BB that can have potential use in the project and as part of the piloting. Then, a conceptual and an empirical framework for evaluation is developed – the former enables the gap analysis of the BB, whereas the latter allows for qualitative and comparative analysis of the BB, as well as extraction of concrete recommendations for piloting. The first phase essentially corresponds to the first three points of the EAAF.&lt;br /&gt;
&lt;br /&gt;
II) The second phase will account for the complete list of project artefacts and will provide empirical validation for the results and recommendations from the first phase. In addition, reassessment of the previous gaps will be performed. This phase will mainly be realized in close collaboration with the pilots: direct feedback via surveys and questionnaires on BB performance will be obtained and the initial conceptual framework will be fine-tuned accordingly. The second phase corresponds to the last point of the EAAF.&lt;br /&gt;
&lt;br /&gt;
=== Conceptual framework ===&lt;br /&gt;
In this section, we first catalogue the BB that are to be considered by the assessment. This step considers the output from D1.5 and establishes a relation to the internal project environment. Then we establish a common conceptualization of the key elements, which is based on the Digital service model, Section 2.2 of the Study on &amp;quot;The feasibility and scenarios for the long-term sustainability of the Large Scale Pilots”. With that, a relation to the external project environment is established. Finally, a basic assessment framework is developed to enable the grading of the BB from several maturity aspects: technical, administrative and operational. The output of the assessment will allow us to perform gap analysis and will also guide the extraction of the piloting recommendations.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''The Digital Services Model: A five-layered approach'''&lt;br /&gt;
&lt;br /&gt;
The LSPs so far have developed building blocks that enable cross-border interoperability based on standards, specifications and common code/components. Therefore, moving beyond the pilot projects and towards actual deployment, it is crucial to develop a structure in which the digital services and the elements they are composed of can be conceptualized.&lt;br /&gt;
&lt;br /&gt;
To establish a conceptual model, it is important to clearly set out the key terminology that is used in relation to the DSI for the provision of cross-border public services. CEF provides an overarching framework suitable for this purpose, called Digital Services Model (DSM). It takes into account the deliverables of the LSPs, the stakeholders and roles they can take on, and the drivers behind the dynamics of this complex ecosystem.&lt;br /&gt;
&lt;br /&gt;
The Digital Services Model is not only needed to establish common terminology and framework, but it is also necessary to analyse the needs and requirements for the future deployment of any digital services, enabling a continuity of the developed methodologies with the LSPs. Thus, it presents the different levels of granularity which need to be taken into consideration for the overall management of the DSI for the provision of public Services.&lt;br /&gt;
&lt;br /&gt;
The following elements represent the main part of the DSM taxonomy:&lt;br /&gt;
&lt;br /&gt;
# Standards and Specifications;&lt;br /&gt;
# Common code or Components;&lt;br /&gt;
# Building Blocks;&lt;br /&gt;
# Core Service Platforms;&lt;br /&gt;
# Generic Services.&lt;br /&gt;
&lt;br /&gt;
Standards and Specifications have been used by all the LSPs for the development of the digital services. These standards and specifications play a central role in interoperability as it means that systems have commonalities in key areas, enabling systems to communicate with one another.&lt;br /&gt;
&lt;br /&gt;
Components are the common code that has been developed for the building blocks. Building blocks are made up of several components (e.g. a timestamp component/functionality). These are often referred to as modules in the deliverables of the LSPs. Component can either be BB-specific or used in several BB.&lt;br /&gt;
&lt;br /&gt;
Essentially, all the solutions derived from the LSPs are ultimately building blocks in the sense that they are services that can be integrated as part of other services. Given the fact that these building blocks have the most obvious potential for reuse across different domains (or Core Service Platforms) these can be seen as a specific layer as part of the set of digital services.&lt;br /&gt;
&lt;br /&gt;
Core Service Platforms enable the provision of cross-border digital services in different domains, like eHealth, eJustice and eProcurement. These are the platforms where all the different BB for a specific service (e.g. eHealth services or eID services) are brought together and made available, enabling service providers to take up and reuse the services as part of their own services. The Core Service Platform (CSP) level should eventually enable the Member States to interact with other Member States through the use of building blocks (via the Generic Services).&lt;br /&gt;
&lt;br /&gt;
It is important to determine what building blocks have been developed by an LSP, as well as which of these are CSP-specific and which are reusable. The CSP-specific blocks are called domain blocks (e.g. ePrescription is specific to eHealth) and the reusable blocks are called building blocks (e.g. eID can be reused in various domains).&lt;br /&gt;
&lt;br /&gt;
The reusable building blocks are the strongest common element between the various CSPs. They therefore need to meet the needs and requirements of all the CSPs. This underlines the links between the building blocks and the CSPs, and the need to manage both of these simultaneously.&lt;br /&gt;
&lt;br /&gt;
Generic Services is the level of abstraction at which the Member States integrate or connect to the CSPs. These interconnections are necessary to link up a Member State so it can provide cross-border access and use of national eIDs, electronic health records, national procurement platforms, national eJustice platforms and public services for foreign business. Each Member State has to ensure that these existing systems at national level are linked up with the CSPs through Generic Services in order to be cross-border enabled.&lt;br /&gt;
&lt;br /&gt;
To define a common taxonomy for BB description prior to the actual assessment, the relevant BB are catalogued in view of the five-layered model described above. This is represented in the figure below (Taxonomy of Building Blocks). &lt;br /&gt;
[[File:Taxonomy of Building Blocks.png|alt=Taxonomy of Building Blocks|Taxonomy of Building Blocks|center|frame]]Although implicitly understandable, it is worth noting that some BB can belong to two different categories, as their application is largely context dependent. In other words, whereas in one context a certain BB can be seen as a Standard/Specification, in another context it can be a Component. In those cases, the more general category is assigned to that BB, giving priority to show its potential rather than its most common use. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Assessment criteria'''&lt;br /&gt;
&lt;br /&gt;
In this section, a basic assessment framework is presented composed of the criteria that guide the expert scoring of BB from the aspect of technical, administrative and operational maturity. The criteria essentially represent a matrix indexed by two dimensions: Score and Maturity aspect. These dimensions, together with the semantics of the criteria (the matrix-cells) are shown in the table below (Conceptual BB assessment framework). For better graphical representation of the empirical assessment that will be performed in the next section, each row is represented by a colour, visually grasping the overall maturity of a certain building block.&lt;br /&gt;
[[File:Conceptual BB assessment framework.png|alt=Conceptual BB assessment framework|center|thumb|600x600px|Conceptual BB assessment framework]]&lt;br /&gt;
The colouring of the framework is not important only for the visual appeal of the reader; rather, it is meant to serve as a concrete input (an additional dimension) for the prospective formalization of the assessment framework. Such formalization would enable a semi- and, ultimately, a fully automatic maturity and quality attributes assessment of both a set of desired (composable) BB, as well as a solution architecture representing a Common Service Platform or a General Service per se. &lt;br /&gt;
&lt;br /&gt;
It is important to note that the framework represented above is a simplified version of the generic assessment framework that will be the final contribution by WP2. This is because at this stage it cannot be expected that all necessary information by the pilots is obtained for an overall architecture evaluation to take place. Such assessment will be performed in the second phase of the ''BB assessment'' task, when the framework from Table 2 will also be further revised and fine-tuned. As a result, the gap analysis in the second phase will take into account the exhaustive set of pilots’ requirements and the pilots’ feedback on the implemented BB.&lt;br /&gt;
&lt;br /&gt;
=== Empirical framework ===&lt;br /&gt;
The empirical framework is essentially an implementation of the conceptual framework with concrete recommendations as an output. While the conceptual framework is based on well-standardized assessment methodologies, the (input to the) empirical evaluation of the BB relies largely on expert opinions and judgements. To close the subjectivity gap between the experts’ evaluation criteria, the BB Assessment group defined an internal process of iterative calibration on the evaluation criteria, as represented by the process flow below:&lt;br /&gt;
[[File:Calibration process for BB evaluation criteria.png|alt=Calibration process for BB evaluation criteria|center|thumb|600x600px|Calibration process for BB evaluation criteria]]&lt;br /&gt;
In the '''Preparatory step''', the building blocks were matched to the experts’ experience and expertise with respect to the capabilities provided by each BB and the architecture principles outlined by the DE4A objectives. One or more groups of BB with shared capabilities were then assigned to each expert for assessment.  &lt;br /&gt;
&lt;br /&gt;
In the '''Assessment step''', the initial evaluation criteria were agreed upon and integrated into the [https://wiki.de4a.eu/index.php/File:Conceptual_BB_assessment_framework.png basic assessment framework]. Then, the results from the initial assessments for each BB were presented in front of the BB Assessment group. This allowed for a constructive discussion on the need to fine-tune the evaluation criteria and to revise the evaluation results. These considerations are part of the '''Fine-tuning step''', which is essentially an iterative procedure on its own, until the complete set of evaluation criteria is obtained, and the BB scores are approved by all experts of the BB Assessment group.&lt;br /&gt;
&lt;br /&gt;
In the '''Recommendation step''', the final scores for each BB were provided for all three maturity aspects: Technical, Administrative and Operational. These are then analysed in view of the piloting requirements and the DE4A objectives as part of the Gap analysis, enabling the extraction of a single Recommendation as an output from the overall process.&lt;br /&gt;
&lt;br /&gt;
The output of the preparatory step is the Taxonomy of BB, whereas the output of the Assessment step is the conceptual framework – further whose criteria, aspects and semantics were fine-tuned in the third step. The scores and recommendations are obtained as an output from the final (Recommendation) step, supported by the argumentation given in the Gap Analysis. For a more complete overview of the final scores and recommendation, they are succinctly represented altogether in the BB recommendations table below. &lt;br /&gt;
&lt;br /&gt;
=== Recommendations and Gap Analysis ===&lt;br /&gt;
This section summarizes the assessment for each building block, by aspect and with an overall recommendation grade. A recommendation is essentially the expert opinion based on the results from the conceptual framework, the gap analysis and in relation to the piloting needs and requirements. The overall list of assessed BB is catalogued as follows:&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|+BB recommendations&lt;br /&gt;
|'''#'''&lt;br /&gt;
|'''Building Block'''&lt;br /&gt;
|'''Technical Maturity'''&lt;br /&gt;
|'''Administrative Maturity'''&lt;br /&gt;
|'''Operational Maturity'''&lt;br /&gt;
|'''Recommendation'''&lt;br /&gt;
|-&lt;br /&gt;
|1&lt;br /&gt;
|eDelivery&lt;br /&gt;
|Implemented  and running&lt;br /&gt;
|Completely  aligned with current EU policies &lt;br /&gt;
|runs  in production in EU (one or more MS) &lt;br /&gt;
|Recommended&lt;br /&gt;
|-&lt;br /&gt;
|2&lt;br /&gt;
|eID&lt;br /&gt;
|Implemented  and running&lt;br /&gt;
|Completely  aligned with current EU policies &lt;br /&gt;
|runs  in production in EU (one or more MS) &lt;br /&gt;
|Recommended&lt;br /&gt;
|-&lt;br /&gt;
|3&lt;br /&gt;
|eSignature&lt;br /&gt;
|Cutting-edge &lt;br /&gt;
|Completely  aligned with current EU policies &lt;br /&gt;
|runs  in production in EU (one or more MS) &lt;br /&gt;
|Recommended&lt;br /&gt;
|-&lt;br /&gt;
|4&lt;br /&gt;
|CCCEV&lt;br /&gt;
|Implemented  and running&lt;br /&gt;
|Completely  aligned with current EU policies &lt;br /&gt;
|Piloted &lt;br /&gt;
|Acceptable&lt;br /&gt;
|-&lt;br /&gt;
|5&lt;br /&gt;
|CPSV-AP&lt;br /&gt;
|Implemented  and running&lt;br /&gt;
|Completely  aligned with current EU policies &lt;br /&gt;
|runs  in production in EU (one or more MS) &lt;br /&gt;
|Acceptable&lt;br /&gt;
|-&lt;br /&gt;
|6&lt;br /&gt;
|eCertis&lt;br /&gt;
|Implemented  and running&lt;br /&gt;
|Completely  aligned with current EU policies &lt;br /&gt;
|EU  infrastructure, broadly accepted &lt;br /&gt;
|Recommended&lt;br /&gt;
|-&lt;br /&gt;
|7&lt;br /&gt;
|eIDAS interoperability  specifications&lt;br /&gt;
|Implemented  and running&lt;br /&gt;
|Completely  aligned with current EU policies &lt;br /&gt;
|runs  in production in EU (one or more MS) &lt;br /&gt;
|Acceptable&lt;br /&gt;
|-&lt;br /&gt;
|8&lt;br /&gt;
|sTESTA&lt;br /&gt;
|Implemented  and running&lt;br /&gt;
|Completely  aligned with current EU policies &lt;br /&gt;
|EU  infrastructure, broadly accepted &lt;br /&gt;
|Discarded&lt;br /&gt;
|-&lt;br /&gt;
|9&lt;br /&gt;
|x-Road&lt;br /&gt;
|Implemented  and running&lt;br /&gt;
|Aligned  with national policies, but is yet to be aligned with the EU&lt;br /&gt;
|runs  in production in EU (one or more MS) &lt;br /&gt;
|Useful&lt;br /&gt;
|-&lt;br /&gt;
|10&lt;br /&gt;
|DCAT-AP&lt;br /&gt;
|Implemented  and running&lt;br /&gt;
|Completely  aligned with current EU policies &lt;br /&gt;
|EU  infrastructure, broadly accepted &lt;br /&gt;
|Acceptable&lt;br /&gt;
|-&lt;br /&gt;
|11&lt;br /&gt;
|BREG-DCAT-AP &lt;br /&gt;
|Not  stable/ under development &lt;br /&gt;
|Acceptable,  but subject to improvement&lt;br /&gt;
|Piloted&lt;br /&gt;
|Acceptable&lt;br /&gt;
|-&lt;br /&gt;
|12&lt;br /&gt;
|ISA2 Multilingual Forms&lt;br /&gt;
|Implemented and running&lt;br /&gt;
|Completely aligned with  current EU policies &lt;br /&gt;
|runs in production in EU  (one or more MS) &lt;br /&gt;
|Acceptable&lt;br /&gt;
|-&lt;br /&gt;
|13&lt;br /&gt;
|EBSI (CEF Blockchain)&lt;br /&gt;
|Not  stable/ under development &lt;br /&gt;
|Acceptable,  but subject to improvement&lt;br /&gt;
|Piloted &lt;br /&gt;
|Useful&lt;br /&gt;
|-&lt;br /&gt;
|14&lt;br /&gt;
|eInvoicing&lt;br /&gt;
|Implemented  and running&lt;br /&gt;
|Completely  aligned with current EU policies &lt;br /&gt;
|EU  infrastructure, broadly accepted &lt;br /&gt;
|Recommended&lt;br /&gt;
|-&lt;br /&gt;
|15&lt;br /&gt;
|eTranslation&lt;br /&gt;
|Implemented  and running&lt;br /&gt;
|Completely  aligned with current EU policies &lt;br /&gt;
|EU  infrastructure, broadly accepted &lt;br /&gt;
|Recommended&lt;br /&gt;
|-&lt;br /&gt;
|16&lt;br /&gt;
|SEMPER&lt;br /&gt;
|Not  stable/ under development &lt;br /&gt;
|Acceptable,  but subject to improvement&lt;br /&gt;
|Piloted&lt;br /&gt;
|Recommended&lt;br /&gt;
|-&lt;br /&gt;
|17&lt;br /&gt;
|BRIS&lt;br /&gt;
|Implemented  and running&lt;br /&gt;
|Completely  aligned with current EU policies &lt;br /&gt;
|EU  infrastructure, broadly accepted &lt;br /&gt;
|Discarded&lt;br /&gt;
|-&lt;br /&gt;
|18&lt;br /&gt;
|TOOP Architecture&lt;br /&gt;
|Implemented and running&lt;br /&gt;
|Aligned with national  policies, but is yet to be aligned with the EU&lt;br /&gt;
|Piloted &lt;br /&gt;
|Recommended&lt;br /&gt;
|-&lt;br /&gt;
|19&lt;br /&gt;
|TOOP CERB&lt;br /&gt;
|Not stable/ under  development &lt;br /&gt;
|Acceptable, but subject  to improvement&lt;br /&gt;
|Piloted &lt;br /&gt;
|Useful&lt;br /&gt;
|-&lt;br /&gt;
|20&lt;br /&gt;
|TOOP DSD&lt;br /&gt;
|Not stable/ under  development &lt;br /&gt;
|Acceptable, but subject  to improvement&lt;br /&gt;
|Piloted &lt;br /&gt;
|Acceptable &lt;br /&gt;
|-&lt;br /&gt;
|21&lt;br /&gt;
|TOOP eDelivery [SMP/SML and BDXL]&lt;br /&gt;
|Cutting-edge &lt;br /&gt;
|Aligned with national  policies, but is yet to be aligned with the EU&lt;br /&gt;
|runs in production in EU  (one or more MS) &lt;br /&gt;
|Recommended&lt;br /&gt;
|-&lt;br /&gt;
|22&lt;br /&gt;
|TOOP EDM&lt;br /&gt;
|Not stable/ under development &lt;br /&gt;
|Acceptable, but subject  to improvement&lt;br /&gt;
|Concept &lt;br /&gt;
|Acceptable&lt;br /&gt;
|-&lt;br /&gt;
|23&lt;br /&gt;
|TOOP TC&lt;br /&gt;
|Implemented and running&lt;br /&gt;
|Aligned with national  policies, but is yet to be aligned with the EU&lt;br /&gt;
|Piloted &lt;br /&gt;
|Recommended&lt;br /&gt;
|-&lt;br /&gt;
|24&lt;br /&gt;
|TOOP Gateway&lt;br /&gt;
|Cutting-edge &lt;br /&gt;
|Aligned with national  policies, but is yet to be aligned with the EU&lt;br /&gt;
|runs in production in EU  (one or more MS) &lt;br /&gt;
|Recommended&lt;br /&gt;
|-&lt;br /&gt;
|25&lt;br /&gt;
|TOOP Testing Tool&lt;br /&gt;
|Not stable/ under  development &lt;br /&gt;
|Acceptable, but subject  to improvement&lt;br /&gt;
|Piloted &lt;br /&gt;
|Acceptable&lt;br /&gt;
|-&lt;br /&gt;
|26&lt;br /&gt;
|ADMS-AP&lt;br /&gt;
|Implemented  and running&lt;br /&gt;
|Completely  aligned with current EU policies &lt;br /&gt;
|EU  infrastructure, broadly accepted &lt;br /&gt;
|Useful&lt;br /&gt;
|-&lt;br /&gt;
|27&lt;br /&gt;
|EDCI&lt;br /&gt;
|Not  stable/ under development &lt;br /&gt;
|Acceptable,  but subject to improvement&lt;br /&gt;
|Piloted&lt;br /&gt;
|&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Useful&lt;br /&gt;
|-&lt;br /&gt;
|28&lt;br /&gt;
|EES&lt;br /&gt;
|Not  stable/ under development &lt;br /&gt;
|Aligned  with national policies, yet to be aligned with the EU&lt;br /&gt;
|Concept&lt;br /&gt;
|Useful&lt;br /&gt;
|-&lt;br /&gt;
|29&lt;br /&gt;
|eTimeStamp&lt;br /&gt;
|Not  stable/ under development &lt;br /&gt;
|Completely  aligned with current EU policies &lt;br /&gt;
|Concept&lt;br /&gt;
|Recommended&lt;br /&gt;
|-&lt;br /&gt;
|30&lt;br /&gt;
|eDocument&lt;br /&gt;
|Not  stable/ under development &lt;br /&gt;
|Acceptable,  but subject to improvement&lt;br /&gt;
|Concept &lt;br /&gt;
|Discarded&lt;br /&gt;
|-&lt;br /&gt;
|31&lt;br /&gt;
|RPAM&lt;br /&gt;
|Implemented  and running&lt;br /&gt;
|Acceptable,  but subject to improvement&lt;br /&gt;
|Piloted &lt;br /&gt;
|Useful&lt;br /&gt;
|-&lt;br /&gt;
|32&lt;br /&gt;
|SMP/SML&lt;br /&gt;
|Cutting-edge &lt;br /&gt;
|Completely  aligned with current EU policies &lt;br /&gt;
|runs in production in EU  (one or more MS) &lt;br /&gt;
|Recommended&lt;br /&gt;
|-&lt;br /&gt;
|33&lt;br /&gt;
|IMI&lt;br /&gt;
|Cutting-edge &lt;br /&gt;
|Completely  aligned with current EU policies &lt;br /&gt;
|EU  infrastructure, broadly accepted &lt;br /&gt;
|Discarded&lt;br /&gt;
|}&lt;br /&gt;
Following is the analysis of the results from the overall assessment from the aspect of the pilots’ needs, the conceptual framework and the overall architectural principles. It is important to note that this is not the exhaustive set of gap analysis, but it serves as a proof of concept for the methodological and assessment choices decisions made. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Pilots needs’ considerations'''&lt;br /&gt;
&lt;br /&gt;
From the table above, it can be noted that, although some of the BB are assessed as immature from some aspect, the final recommendation is still for them to be used by the pilots. This is due to the fact that, regardless of the current state of maturity, when matched with the pilots’ requirements, some a BB may still have the necessary architecture capabilities that require adjustment in the DE4A context. For instance, this is the case with SEMPER. The SEMPER extension to eIDAS is not fully mature yet but is the only cross-border functionality for working with proxies that currently mandates successfully piloted. Otherwise, there will be a need to develop a DE4A-specific solution for cross-border powers validation from the scratch, which is bot not useful and not feasible within the project timeframe. In order for SEMPER to gain a broader user-base, it has to be validated by more Member States (currently, it has been piloted with 4 MS). In addition, SEMPER has been piloted with legal persons only. Although this is sufficient to the DBA pilot, this is not the case for the moving abroad and studying abroad, as there is a need for piloting with natural persons. The DE4A pilots themselves may be used for this. Finally, SEMPER extends eIDAS, but has not been handed over to DIGIT yet. Therefore, it has not been incorporated in the eIDAS reference software of DIGIT yet. Integration in eIDAS will improve sustainability of the SEMPER extension. Concretely, SEMPER would benefit from eIDAS-like specifications to allow Member States that do not use the eIDAS reference software to develop their own extension based on these specifications. &lt;br /&gt;
&lt;br /&gt;
In contrast to SEMPER, there is also a case where a BB may be assessed as completely mature in most of the aspects but is still disregarded at the Recommendations stage. This is, for instance, the case with the IMI BB, which despite the overall high maturity in all aspects is out of the scope of the DE4A project. Similarly, the BRIS building block has a scope that is much narrower (especially from an administrative perspective) than the scope of DE4A and is therefore not to be used by the pilots. More concretely, BRIS has been developed for inter-business register communication, which is not the primary focus of the DBA pilot (the functional shortcomings on BRIS for piloting in DBA (D4.5, annex V) have been confirmed by DG DIGIT and there is no BRIS-roadmap foreseen that will deliver a solution to the findings). Furthermore, it is legally not feasible to use the BRIS-network for the DE4A-pilots (currently not allowed for non-business registers). An alternative is being discussed with DIGIT: a message broking platform as a possible future BRIS-wide solution that is piloted in TOOP. However, funding for continuation of the platform is not arranged and the current intention is to bring the (cloud-based) prototype infrastructure down when TOOP testing ends.&lt;br /&gt;
&lt;br /&gt;
Similar reasoning in compiling the overall recommendation score is applied to the other building blocks. These considerations have been discussed in detail at the BB Assessment Group meetings during the Recommendation step of the empirical framework. It is out of scope of the deliverable to present a detailed overview of each BB. However, the subtlety of some of the assessment criteria (such as context dependence) is also an argument to justify the decision to rely only on the experts’ evaluations in the first phase of the methodology.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Assessment outcomes considerations'''&lt;br /&gt;
&lt;br /&gt;
Out of the 33 assessed BB, 13 BB are Recommended for implementation, 9 are Acceptable, 7 are Useful and 4 are Discarded. From a maturity point of view: in terms of technical maturity, 5 are cutting-edge, 18 are implemented and running in an operational environment, whereas 10 are not stable or under development. From an administrative maturity aspect, almost half (17) of the BB are completely aligned with current EU policies; 7 are aligned with national policies but are yet to be consolidated at an EU level, whereas 9 (although acceptable) are still subject to further improvements. &lt;br /&gt;
[[File:Taxonomy of assessed BB with their recommendations .png|alt=Taxonomy of assessed BBs with their recommendations |center|frame|Taxonomy of assessed BB with their recommendations ]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
From operational maturity aspect, there are 8 BB which are broadly accepted as part of an EU infrastructure, 12 that run in production in one or more Member States and 10 that are piloted within some kind of operational or testing environment. It is interesting to note that the only aspect by which a BB has been assessed as immature is the Operational aspect. Thus, there are 4 BB (TOOD EDM, EES, eTimeStamp and eDocument) that are marked as operationally immature, as they are only at the stage of a Concept and are yet to be developed.&lt;br /&gt;
&lt;br /&gt;
From a BB type aspect (also visible in the figure above), most of the recommended BB are of the type ‘Building Block’ (7 out of 13) and ‘Standards and specifications’, whereas the ‘General services’ and the ‘Core service platforms’ are the least numerous and the most immature. This is expected, as the later are also the most complex ones and only few in number across EU. &lt;br /&gt;
&lt;br /&gt;
It is also notable that most of the BB considered for use by the pilots are in a mature and useful state that allows reusability and potential upgrades before implementation in the DE4A pilots. Such considerations are already being made (as discussed in the previous subsection) and are part of the piloting requirements to be assessed in the second phase of the methodology. &lt;br /&gt;
&lt;br /&gt;
'''Architecture framework considerations'''&lt;br /&gt;
&lt;br /&gt;
As outlined in the methodological considerations above, the two phases of the overall methodology follow the Enterprise Architecture Assessment Framework principles, with the additional step of providing recommendations for the pilot in between the two phases. Such an approach allows, in addition to the qualitative evaluation, to obtain e quantitative score for the maturity of the overall architecture as a (sub)set of the assessed BB. In that sense, while the output of the EAAF is a maturity level assessment of the overall architecture, the phased approach in DE4A creates an intermediate feedback loop between the pilots and the Project Start Architecture, allowing for adaptable integration of the assessment methodology within the WP2 change management.&lt;br /&gt;
&lt;br /&gt;
Regardless of the incomplete overall assessment, it is still possible to have a quantitative assessment for a solution architecture after the first assessment phase. However, this is not to be considered as the overall architecture framework maturity level, but only as a ‘current maturity level’ of the solution architecture comprised of a given set of BB. Such value can serve as a reference point to be compared upon a given KPI for the overall maturity, in case there is such requirement.&lt;br /&gt;
&lt;br /&gt;
In order to compile a single value for the current maturity level for a pilot solution architecture, the set of BB assessments and their recommendations shall be compared upon the baseline for the EAAF maturity levels.&lt;br /&gt;
[[File:EAAF Maturity levels.png|alt=EAAF Maturity levels|center|frame|EAAF Maturity levels]]&lt;br /&gt;
In the context of DE4A, we will provide such assessment in the second phase of implementation of this methodology, as currently there is no definite list of BB matched to the specific pilots.&lt;/div&gt;</summary>
		<author><name>Ictu mavi.cristache</name></author>
	</entry>
	<entry>
		<id>https://wiki.de4a.eu/index.php?title=Building_Blocks&amp;diff=2999</id>
		<title>Building Blocks</title>
		<link rel="alternate" type="text/html" href="https://wiki.de4a.eu/index.php?title=Building_Blocks&amp;diff=2999"/>
		<updated>2021-07-15T16:24:01Z</updated>

		<summary type="html">&lt;p&gt;Ictu mavi.cristache: /* Conceptual framework */ more content migrated from d2.4&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The purpose of the Building Blocks (BB) assessment is to assess the suitability of the BB identified and catalogued in Task 1.5 for use within the DE4A project. Thus, it bridges outputs from WP1 and requirements from WP4 to provide input for the technical, operational and administrative considerations in the architectural assessments carried out here. Over 40 BB have been considered for this assessment, 31 of which are assessed at the first phase of this work. The results of the assessment show that there is a mature and acceptable stock of solution building blocks that can be considered as potential candidates for implementation by the pilots, either in their entirety or partially, with the needed upgrades.&lt;br /&gt;
&lt;br /&gt;
== Theoretical background ==&lt;br /&gt;
&lt;br /&gt;
=== Objectives and scope ===&lt;br /&gt;
To reach the goal outlined above, this section delves into the architectural evaluation of the building blocks catalogued as useful for DE4A. It is important to note that the term “building block” in the context of this assessment refers to a Solution Building Block in TOGAF sense. &lt;br /&gt;
&lt;br /&gt;
The most important step in assessing the BB is determining the methodology that would support a common description framework of the BB, while providing means for determining the quantitative and/or qualitative evaluation criteria of the considered BB. The outcome of the assessment is a succinct list of recommendations for BB use by the pilots in WP4. In addition to defining the methodology, a gap analysis is performed based on both the pilots’ requirements and the common description framework of the BB, considering the results from the assessment, the project requirements and the common PSA principles. The overall process of conceptual considerations, empirical evaluation, gap analysis and piloting recommendations are denoted as a DE4A generic methodology for architecture building blocks evaluation.&lt;br /&gt;
&lt;br /&gt;
=== Available methodologies ===&lt;br /&gt;
In order to provide continuity and justification of the methodology that is being developed, we first outline and assess the suitability of the currently available methodologies in view of the implementation context and the objectives of the DE4A project. To that end, both generic EU/EC assessment methodologies and past LSP project-specific methodologies are considered.&lt;br /&gt;
&lt;br /&gt;
==== Common assessment method for standards and specifications (CAMSS) ====&lt;br /&gt;
[https://ec.europa.eu/isa2/solutions/camss_en CAMSS] is part of the ISA² interoperability solutions evaluation toolkit for public administrations, businesses and citizens. It provides a method to assist in the assessment of ICT standards and specifications. The main objective of CAMSS is achieving interoperability and avoiding vendor lock-in. In that sense, CAMSS criteria evaluate (among other things) the openness of standards and specifications. This is done by employing the CAMSS tools and adapting the evaluation according to the needs of an individual Member State.&lt;br /&gt;
&lt;br /&gt;
In the context of DE4A, relying solely on CAMSS does not provide the means for BB suitability and gap analysis in relation to the piloting needs. Moreover, it does not provide any selection criteria or a taxonomy for consistent mapping of the different BB onto a common comparable framework.&lt;br /&gt;
&lt;br /&gt;
==== Past project-specific methodologies ====&lt;br /&gt;
'''eSENS'''&lt;br /&gt;
&lt;br /&gt;
eSENS has developed its own methodology for BB assessment, which is mainly an adaptation of CAMSS and Asset Description Metadata Schema (ADMS), supported by inputs of the [https://web.archive.org/web/20200928232327/http://www.esens.eu/deliverables eSENS deliverable D6.1] (see Table 5 in [https://web.archive.org/web/20200928232327/http://www.esens.eu/deliverables eSENS D3.1]). Its objective is to propose a documentation of format and defining criteria for the maturity and sustainability assessment of building blocks. The overall framework consists of three steps: 1) The Consideration step; 2) The Assessment step; and 3) The Recommendation step and produces a list of assessment criteria to be used for BB evaluation. These criteria, however, are very general and not architecture-specific – their applicability is valid and valuable only if used in collaboration with the legal, business, organizational, technical and implementation team.&lt;br /&gt;
&lt;br /&gt;
It is important to note that the assessment methodology employed in eSENS is developed with a different aim from ours – its analysis and recommendations refer to the desired BB qualities that are needed to ensure meeting the maturity levels and the sustainability criteria envisaged by the project. Thus, although it produces guidelines for assessment, it does not provide concrete output in terms of actual scores, analysis and recommendations for BB. Moreover, it does not provide a comparable baseline when multiple BB have to be considered for the same pilot and it is based on the assumption that the existing BB represent the exhaustive list of possible solutions from which a suitable match should be chosen. In the case of DE4A, such an assumption does not hold, as there may be a case where a certain BB is not mature enough to be recommended for piloting but is also not to be completely disregarded either. More importantly, the methodology developed here is used for actual assessment and is to be fine-tuned at a later stage in connection to the general architecture lifecycle development.&lt;br /&gt;
&lt;br /&gt;
'''TOOP'''&lt;br /&gt;
&lt;br /&gt;
Like eSENS, the overall idea of the TOOP assessment methodology is to reuse existing frameworks and building blocks provided by CEF, eSENS, and other initiatives. First, an initial inventory of existing e- Government building blocks is proposed. Then, the principles of selection of building blocks for OOP applications are provided, together with high-level views of the architecture. Finally, an analysis of selected building blocks is done with respect to their relevance, applicability, sustainability, need for further development and external interfaces.&lt;br /&gt;
&lt;br /&gt;
The main criteria for inclusion of a building block in TOOP are:&lt;br /&gt;
&lt;br /&gt;
* The specific project requirements;&lt;br /&gt;
* The TOOP pilots’ needs;&lt;br /&gt;
* Usability in long-term applications (maintenance and support provided).&lt;br /&gt;
&lt;br /&gt;
As a result, the building blocks are categorized into three basic groups:&lt;br /&gt;
&lt;br /&gt;
# BB that provide capabilities needed by all or most TOOP Pilot Areas;&lt;br /&gt;
# BB that provide capabilities needed or probably needed by some TOOP Pilot Areas;&lt;br /&gt;
# BB that provide capabilities not needed by the TOOP Pilot Areas.&lt;br /&gt;
&lt;br /&gt;
TOOP’s criteria are tightly bound to the piloting needs, whereas the rationale behind their choice is OOP-specific rather than generic. The methodology here follows a similar line of reasoning, but differs in the conceptual framework, which is more formally defined and made reusable by other projects as well. &lt;br /&gt;
&lt;br /&gt;
==== ISA2 Interim Evaluation ====&lt;br /&gt;
The [https://ec.europa.eu/isa2/sites/isa/files/190613_synopsis_report.pdf interim evaluation] aimed to assess how well the ISA² Programme has performed since its start in 2016 and whether its existence continues to be justified. Based on stakeholders’ views, opinions and public consultation, it evaluated the implementation of the programme based on seven criteria and identified several points for improvement. &lt;br /&gt;
&lt;br /&gt;
The evaluation criteria considered were: Relevance (the alignment between the objectives of the programme and the current needs and problems experienced by stakeholders); Effectiveness (the extent to which the programme has achieved its objectives); Efficiency (the extent to which the programme’s objectives are achieved at a minimum cost); Coherence (the alignment between the programme and comparable EU initiatives as well as the overall EU policy framework); EU added value (the additional impacts generated by the programme, as opposed to leaving the subject matter in the hands of Member States); Utility (the extent to which the programme meets stakeholders’ needs); and Sustainability (the likelihood that the programme’s results will last beyond its completion).&lt;br /&gt;
&lt;br /&gt;
However, the interim evaluation does not provide a specific methodology – either in terms of criteria choice, or in terms of architectural or future piloting recommendations. Its value lies mainly in the identification of possible gaps that exist within the current EU architecture framework even prior to the implementation of the available building blocks. In that sense, the main recommendations for prospective actions are determined in awareness raising beyond national administrations; moving from user-centric to user-driven solutions; and working towards increased sustainability.&lt;br /&gt;
&lt;br /&gt;
Our work integrates the interim evaluation criteria even at the stage of cataloguing BB relevant in DE4A context. More importantly, it takes into consideration the methodological gaps identified in the assessment in terms of awareness, user-driven solutions and sustainability prescriptions and integrates specific technical, administrative and operational aspects in the recommendation’s extraction for the pilots. &lt;br /&gt;
&lt;br /&gt;
==== EAAF ====&lt;br /&gt;
The [https://obamawhitehouse.archives.gov/sites/default/files/omb/assets/fea_docs/OMB_EA_Assessment_Framework_v3_1_June_2009.pdf Enterprise Architecture Assessment Framework (EAAF)] assists the US government in the assessment and reporting of their enterprise architecture activity and maturity, as well as in the advancement of the use of enterprise architecture to guide political decisions on IT investments. In addition to providing the methods for the assessment, EAAF also identifies the measurement areas and criteria by which government agencies are to rely on the architecture to drive performance improvements. This is integrated into the so-called Performance Improvement Lifecycle, where points for improvement are identified and translated into specific actions.&lt;br /&gt;
&lt;br /&gt;
In that sense, the framework provides a good overall methodology for the assessment of DE4A BB. Following its guidelines, in order to perform the technical assessment, the architects, together with the relevant project partners (mainly from WP1 and WP4):&lt;br /&gt;
&lt;br /&gt;
* Identify and prioritize the BB considering the pilots’ needs and in view of the project goals and objectives;&lt;br /&gt;
* Determine specific methodological steps for gap analysis, using common or shared information assets and information technology assets;&lt;br /&gt;
* Quantify/qualify and assess the performance to verify compliance with pilots’ requirements and provide report on gap closure; and&lt;br /&gt;
* Assess feedback on the pilots’ performance in order to enhance the architecture and fine-tune the assessment methodology for future implementation decisions.&lt;br /&gt;
&lt;br /&gt;
=== Methodological considerations ===&lt;br /&gt;
The need to develop a generic methodology that integrates some aspects of the standardized methodologies, but does not rely on a single one, is based on several considerations: &lt;br /&gt;
&lt;br /&gt;
# The assessment methodologies currently available either focus on alignment of the BB specifications or are only concerned with the maturity of the solution provided by the building blocks; &lt;br /&gt;
# They do not provide a clear definition of the common principles for assessment;&lt;br /&gt;
# They do not allow for a phased-approach to the assessment and are applicable either for a single BB or for a finalized solution architecture (Note: Although EAAF prescribes the principles for a phased assessment, it does not delineate the phases explicitly and only gives a requirement for the overall outcome of the assessment). &lt;br /&gt;
&lt;br /&gt;
As a result, the architect is prevented from developing an assessment for multiple BB with varying levels of complexity and is also disabled to perform comparative evaluation for determining the best fit for a particular solution architecture. &lt;br /&gt;
&lt;br /&gt;
The methodology developed here is novel in that it addresses the points above and is also generic in the sense that it can be reused by other large-scale projects for similar purposes. It incorporates the assessment principles of existing standards-based methodologies (like CAMSS and EAAF) taking into account the architecture feasibility and sustainability, but it also generalizes these principles over the context of implementation required by DE4A.&lt;br /&gt;
&lt;br /&gt;
== Methodology ==&lt;br /&gt;
In order to account for both the piloting recommendations criteria and the performance assessment criteria, the overall methodology requires a phased approach. Therefore, it consists of two phases:&lt;br /&gt;
&lt;br /&gt;
I) The first phase takes stock of the entire list of BB that can have potential use in the project and as part of the piloting. Then, a conceptual and an empirical framework for evaluation is developed – the former enables the gap analysis of the BB, whereas the latter allows for qualitative and comparative analysis of the BB, as well as extraction of concrete recommendations for piloting. The first phase essentially corresponds to the first three points of the EAAF.&lt;br /&gt;
&lt;br /&gt;
II) The second phase will account for the complete list of project artefacts and will provide empirical validation for the results and recommendations from the first phase. In addition, reassessment of the previous gaps will be performed. This phase will mainly be realized in close collaboration with the pilots: direct feedback via surveys and questionnaires on BB performance will be obtained and the initial conceptual framework will be fine-tuned accordingly. The second phase corresponds to the last point of the EAAF.&lt;br /&gt;
&lt;br /&gt;
=== Conceptual framework ===&lt;br /&gt;
In this section, we first catalogue the BB that are to be considered by the assessment. This step considers the output from D1.5 and establishes a relation to the internal project environment. Then we establish a common conceptualization of the key elements, which is based on the Digital service model, Section 2.2 of the Study on &amp;quot;The feasibility and scenarios for the long-term sustainability of the Large Scale Pilots”. With that, a relation to the external project environment is established. Finally, a basic assessment framework is developed to enable the grading of the BB from several maturity aspects: technical, administrative and operational. The output of the assessment will allow us to perform gap analysis and will also guide the extraction of the piloting recommendations.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''The Digital Services Model: A five-layered approach'''&lt;br /&gt;
&lt;br /&gt;
The LSPs so far have developed building blocks that enable cross-border interoperability based on standards, specifications and common code/components. Therefore, moving beyond the pilot projects and towards actual deployment, it is crucial to develop a structure in which the digital services and the elements they are composed of can be conceptualized.&lt;br /&gt;
&lt;br /&gt;
To establish a conceptual model, it is important to clearly set out the key terminology that is used in relation to the DSI for the provision of cross-border public services. CEF provides an overarching framework suitable for this purpose, called Digital Services Model (DSM). It takes into account the deliverables of the LSPs, the stakeholders and roles they can take on, and the drivers behind the dynamics of this complex ecosystem.&lt;br /&gt;
&lt;br /&gt;
The Digital Services Model is not only needed to establish common terminology and framework, but it is also necessary to analyse the needs and requirements for the future deployment of any digital services, enabling a continuity of the developed methodologies with the LSPs. Thus, it presents the different levels of granularity which need to be taken into consideration for the overall management of the DSI for the provision of public Services.&lt;br /&gt;
&lt;br /&gt;
The following elements represent the main part of the DSM taxonomy:&lt;br /&gt;
&lt;br /&gt;
# Standards and Specifications;&lt;br /&gt;
# Common code or Components;&lt;br /&gt;
# Building Blocks;&lt;br /&gt;
# Core Service Platforms;&lt;br /&gt;
# Generic Services.&lt;br /&gt;
&lt;br /&gt;
Standards and Specifications have been used by all the LSPs for the development of the digital services. These standards and specifications play a central role in interoperability as it means that systems have commonalities in key areas, enabling systems to communicate with one another.&lt;br /&gt;
&lt;br /&gt;
Components are the common code that has been developed for the building blocks. Building blocks are made up of several components (e.g. a timestamp component/functionality). These are often referred to as modules in the deliverables of the LSPs. Component can either be BB-specific or used in several BB.&lt;br /&gt;
&lt;br /&gt;
Essentially, all the solutions derived from the LSPs are ultimately building blocks in the sense that they are services that can be integrated as part of other services. Given the fact that these building blocks have the most obvious potential for reuse across different domains (or Core Service Platforms) these can be seen as a specific layer as part of the set of digital services.&lt;br /&gt;
&lt;br /&gt;
Core Service Platforms enable the provision of cross-border digital services in different domains, like eHealth, eJustice and eProcurement. These are the platforms where all the different BB for a specific service (e.g. eHealth services or eID services) are brought together and made available, enabling service providers to take up and reuse the services as part of their own services. The Core Service Platform (CSP) level should eventually enable the Member States to interact with other Member States through the use of building blocks (via the Generic Services).&lt;br /&gt;
&lt;br /&gt;
It is important to determine what building blocks have been developed by an LSP, as well as which of these are CSP-specific and which are reusable. The CSP-specific blocks are called domain blocks (e.g. ePrescription is specific to eHealth) and the reusable blocks are called building blocks (e.g. eID can be reused in various domains).&lt;br /&gt;
&lt;br /&gt;
The reusable building blocks are the strongest common element between the various CSPs. They therefore need to meet the needs and requirements of all the CSPs. This underlines the links between the building blocks and the CSPs, and the need to manage both of these simultaneously.&lt;br /&gt;
&lt;br /&gt;
Generic Services is the level of abstraction at which the Member States integrate or connect to the CSPs. These interconnections are necessary to link up a Member State so it can provide cross-border access and use of national eIDs, electronic health records, national procurement platforms, national eJustice platforms and public services for foreign business. Each Member State has to ensure that these existing systems at national level are linked up with the CSPs through Generic Services in order to be cross-border enabled.&lt;br /&gt;
&lt;br /&gt;
To define a common taxonomy for BB description prior to the actual assessment, the relevant BB are catalogued in view of the five-layered model described above. This is represented in the figure below (Taxonomy of Building Blocks). &lt;br /&gt;
[[File:Taxonomy of Building Blocks.png|alt=Taxonomy of Building Blocks|Taxonomy of Building Blocks|center|frame]]Although implicitly understandable, it is worth noting that some BB can belong to two different categories, as their application is largely context dependent. In other words, whereas in one context a certain BB can be seen as a Standard/Specification, in another context it can be a Component. In those cases, the more general category is assigned to that BB, giving priority to show its potential rather than its most common use. &lt;br /&gt;
&lt;br /&gt;
==== Assessment criteria ====&lt;br /&gt;
In this section, a basic assessment framework is presented composed of the criteria that guide the expert scoring of BB from the aspect of technical, administrative and operational maturity. The criteria essentially represent a matrix indexed by two dimensions: Score and Maturity aspect. These dimensions, together with the semantics of the criteria (the matrix-cells) are shown in the table below (Conceptual BB assessment framework). For better graphical representation of the empirical assessment that will be performed in the next section, each row is represented by a colour, visually grasping the overall maturity of a certain building block.&lt;br /&gt;
[[File:Conceptual BB assessment framework.png|alt=Conceptual BB assessment framework|center|thumb|600x600px|Conceptual BB assessment framework]]&lt;br /&gt;
The colouring of the framework is not important only for the visual appeal of the reader; rather, it is meant to serve as a concrete input (an additional dimension) for the prospective formalization of the assessment framework. Such formalization would enable a semi- and, ultimately, a fully automatic maturity and quality attributes assessment of both a set of desired (composable) BB, as well as a solution architecture representing a Common Service Platform or a General Service per se. &lt;br /&gt;
&lt;br /&gt;
It is important to note that the framework represented above is a simplified version of the generic assessment framework that will be the final contribution by WP2. This is because at this stage it cannot be expected that all necessary information by the pilots is obtained for an overall architecture evaluation to take place. Such assessment will be performed in the second phase of the ''BB assessment'' task, when the framework from Table 2 will also be further revised and fine-tuned. As a result, the gap analysis in the second phase will take into account the exhaustive set of pilots’ requirements and the pilots’ feedback on the implemented BB.&lt;br /&gt;
&lt;br /&gt;
=== Empirical framework ===&lt;br /&gt;
The empirical framework is essentially an implementation of the conceptual framework with concrete recommendations as an output. While the conceptual framework is based on well-standardized assessment methodologies, the (input to the) empirical evaluation of the BB relies largely on expert opinions and judgements. To close the subjectivity gap between the experts’ evaluation criteria, the BB Assessment group defined an internal process of iterative calibration on the evaluation criteria, as represented by the process flow below:&lt;br /&gt;
[[File:Calibration process for BB evaluation criteria.png|alt=Calibration process for BB evaluation criteria|center|thumb|600x600px|Calibration process for BB evaluation criteria]]&lt;br /&gt;
In the '''Preparatory step''', the building blocks were matched to the experts’ experience and expertise with respect to the capabilities provided by each BB and the architecture principles outlined by the DE4A objectives. One or more groups of BB with shared capabilities were then assigned to each expert for assessment.  &lt;br /&gt;
&lt;br /&gt;
In the '''Assessment step''', the initial evaluation criteria were agreed upon and integrated into the [https://wiki.de4a.eu/index.php/File:Conceptual_BB_assessment_framework.png basic assessment framework]. Then, the results from the initial assessments for each BB were presented in front of the BB Assessment group. This allowed for a constructive discussion on the need to fine-tune the evaluation criteria and to revise the evaluation results. These considerations are part of the '''Fine-tuning step''', which is essentially an iterative procedure on its own, until the complete set of evaluation criteria is obtained, and the BB scores are approved by all experts of the BB Assessment group.&lt;br /&gt;
&lt;br /&gt;
In the '''Recommendation step''', the final scores for each BB were provided for all three maturity aspects: Technical, Administrative and Operational. These are then analysed in view of the piloting requirements and the DE4A objectives as part of the Gap analysis, enabling the extraction of a single Recommendation as an output from the overall process.&lt;br /&gt;
&lt;br /&gt;
The output of the preparatory step is the Taxonomy of BB, whereas the output of the Assessment step is the conceptual framework – further whose criteria, aspects and semantics were fine-tuned in the third step. The scores and recommendations are obtained as an output from the final (Recommendation) step, supported by the argumentation given in the Gap Analysis. For a more complete overview of the final scores and recommendation, they are succinctly represented altogether in the BB recommendations table below. &lt;br /&gt;
&lt;br /&gt;
=== Recommendations and Gap Analysis ===&lt;br /&gt;
This section summarizes the assessment for each building block, by aspect and with an overall recommendation grade. A recommendation is essentially the expert opinion based on the results from the conceptual framework, the gap analysis and in relation to the piloting needs and requirements. The overall list of assessed BB is catalogued as follows:&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot;&lt;br /&gt;
|+BB recommendations&lt;br /&gt;
|'''#'''&lt;br /&gt;
|'''Building Block'''&lt;br /&gt;
|'''Technical Maturity'''&lt;br /&gt;
|'''Administrative Maturity'''&lt;br /&gt;
|'''Operational Maturity'''&lt;br /&gt;
|'''Recommendation'''&lt;br /&gt;
|-&lt;br /&gt;
|1&lt;br /&gt;
|eDelivery&lt;br /&gt;
|Implemented  and running&lt;br /&gt;
|Completely  aligned with current EU policies &lt;br /&gt;
|runs  in production in EU (one or more MS) &lt;br /&gt;
|Recommended&lt;br /&gt;
|-&lt;br /&gt;
|2&lt;br /&gt;
|eID&lt;br /&gt;
|Implemented  and running&lt;br /&gt;
|Completely  aligned with current EU policies &lt;br /&gt;
|runs  in production in EU (one or more MS) &lt;br /&gt;
|Recommended&lt;br /&gt;
|-&lt;br /&gt;
|3&lt;br /&gt;
|eSignature&lt;br /&gt;
|Cutting-edge &lt;br /&gt;
|Completely  aligned with current EU policies &lt;br /&gt;
|runs  in production in EU (one or more MS) &lt;br /&gt;
|Recommended&lt;br /&gt;
|-&lt;br /&gt;
|4&lt;br /&gt;
|CCCEV&lt;br /&gt;
|Implemented  and running&lt;br /&gt;
|Completely  aligned with current EU policies &lt;br /&gt;
|Piloted &lt;br /&gt;
|Acceptable&lt;br /&gt;
|-&lt;br /&gt;
|5&lt;br /&gt;
|CPSV-AP&lt;br /&gt;
|Implemented  and running&lt;br /&gt;
|Completely  aligned with current EU policies &lt;br /&gt;
|runs  in production in EU (one or more MS) &lt;br /&gt;
|Acceptable&lt;br /&gt;
|-&lt;br /&gt;
|6&lt;br /&gt;
|eCertis&lt;br /&gt;
|Implemented  and running&lt;br /&gt;
|Completely  aligned with current EU policies &lt;br /&gt;
|EU  infrastructure, broadly accepted &lt;br /&gt;
|Recommended&lt;br /&gt;
|-&lt;br /&gt;
|7&lt;br /&gt;
|eIDAS interoperability  specifications&lt;br /&gt;
|Implemented  and running&lt;br /&gt;
|Completely  aligned with current EU policies &lt;br /&gt;
|runs  in production in EU (one or more MS) &lt;br /&gt;
|Acceptable&lt;br /&gt;
|-&lt;br /&gt;
|8&lt;br /&gt;
|sTESTA&lt;br /&gt;
|Implemented  and running&lt;br /&gt;
|Completely  aligned with current EU policies &lt;br /&gt;
|EU  infrastructure, broadly accepted &lt;br /&gt;
|Discarded&lt;br /&gt;
|-&lt;br /&gt;
|9&lt;br /&gt;
|x-Road&lt;br /&gt;
|Implemented  and running&lt;br /&gt;
|Aligned  with national policies, but is yet to be aligned with the EU&lt;br /&gt;
|runs  in production in EU (one or more MS) &lt;br /&gt;
|Useful&lt;br /&gt;
|-&lt;br /&gt;
|10&lt;br /&gt;
|DCAT-AP&lt;br /&gt;
|Implemented  and running&lt;br /&gt;
|Completely  aligned with current EU policies &lt;br /&gt;
|EU  infrastructure, broadly accepted &lt;br /&gt;
|Acceptable&lt;br /&gt;
|-&lt;br /&gt;
|11&lt;br /&gt;
|BREG-DCAT-AP &lt;br /&gt;
|Not  stable/ under development &lt;br /&gt;
|Acceptable,  but subject to improvement&lt;br /&gt;
|Piloted&lt;br /&gt;
|Acceptable&lt;br /&gt;
|-&lt;br /&gt;
|12&lt;br /&gt;
|ISA2 Multilingual Forms&lt;br /&gt;
|Implemented and running&lt;br /&gt;
|Completely aligned with  current EU policies &lt;br /&gt;
|runs in production in EU  (one or more MS) &lt;br /&gt;
|Acceptable&lt;br /&gt;
|-&lt;br /&gt;
|13&lt;br /&gt;
|EBSI (CEF Blockchain)&lt;br /&gt;
|Not  stable/ under development &lt;br /&gt;
|Acceptable,  but subject to improvement&lt;br /&gt;
|Piloted &lt;br /&gt;
|Useful&lt;br /&gt;
|-&lt;br /&gt;
|14&lt;br /&gt;
|eInvoicing&lt;br /&gt;
|Implemented  and running&lt;br /&gt;
|Completely  aligned with current EU policies &lt;br /&gt;
|EU  infrastructure, broadly accepted &lt;br /&gt;
|Recommended&lt;br /&gt;
|-&lt;br /&gt;
|15&lt;br /&gt;
|eTranslation&lt;br /&gt;
|Implemented  and running&lt;br /&gt;
|Completely  aligned with current EU policies &lt;br /&gt;
|EU  infrastructure, broadly accepted &lt;br /&gt;
|Recommended&lt;br /&gt;
|-&lt;br /&gt;
|16&lt;br /&gt;
|SEMPER&lt;br /&gt;
|Not  stable/ under development &lt;br /&gt;
|Acceptable,  but subject to improvement&lt;br /&gt;
|Piloted&lt;br /&gt;
|Recommended&lt;br /&gt;
|-&lt;br /&gt;
|17&lt;br /&gt;
|BRIS&lt;br /&gt;
|Implemented  and running&lt;br /&gt;
|Completely  aligned with current EU policies &lt;br /&gt;
|EU  infrastructure, broadly accepted &lt;br /&gt;
|Discarded&lt;br /&gt;
|-&lt;br /&gt;
|18&lt;br /&gt;
|TOOP Architecture&lt;br /&gt;
|Implemented and running&lt;br /&gt;
|Aligned with national  policies, but is yet to be aligned with the EU&lt;br /&gt;
|Piloted &lt;br /&gt;
|Recommended&lt;br /&gt;
|-&lt;br /&gt;
|19&lt;br /&gt;
|TOOP CERB&lt;br /&gt;
|Not stable/ under  development &lt;br /&gt;
|Acceptable, but subject  to improvement&lt;br /&gt;
|Piloted &lt;br /&gt;
|Useful&lt;br /&gt;
|-&lt;br /&gt;
|20&lt;br /&gt;
|TOOP DSD&lt;br /&gt;
|Not stable/ under  development &lt;br /&gt;
|Acceptable, but subject  to improvement&lt;br /&gt;
|Piloted &lt;br /&gt;
|Acceptable &lt;br /&gt;
|-&lt;br /&gt;
|21&lt;br /&gt;
|TOOP eDelivery [SMP/SML and BDXL]&lt;br /&gt;
|Cutting-edge &lt;br /&gt;
|Aligned with national  policies, but is yet to be aligned with the EU&lt;br /&gt;
|runs in production in EU  (one or more MS) &lt;br /&gt;
|Recommended&lt;br /&gt;
|-&lt;br /&gt;
|22&lt;br /&gt;
|TOOP EDM&lt;br /&gt;
|Not stable/ under development &lt;br /&gt;
|Acceptable, but subject  to improvement&lt;br /&gt;
|Concept &lt;br /&gt;
|Acceptable&lt;br /&gt;
|-&lt;br /&gt;
|23&lt;br /&gt;
|TOOP TC&lt;br /&gt;
|Implemented and running&lt;br /&gt;
|Aligned with national  policies, but is yet to be aligned with the EU&lt;br /&gt;
|Piloted &lt;br /&gt;
|Recommended&lt;br /&gt;
|-&lt;br /&gt;
|24&lt;br /&gt;
|TOOP Gateway&lt;br /&gt;
|Cutting-edge &lt;br /&gt;
|Aligned with national  policies, but is yet to be aligned with the EU&lt;br /&gt;
|runs in production in EU  (one or more MS) &lt;br /&gt;
|Recommended&lt;br /&gt;
|-&lt;br /&gt;
|25&lt;br /&gt;
|TOOP Testing Tool&lt;br /&gt;
|Not stable/ under  development &lt;br /&gt;
|Acceptable, but subject  to improvement&lt;br /&gt;
|Piloted &lt;br /&gt;
|Acceptable&lt;br /&gt;
|-&lt;br /&gt;
|26&lt;br /&gt;
|ADMS-AP&lt;br /&gt;
|Implemented  and running&lt;br /&gt;
|Completely  aligned with current EU policies &lt;br /&gt;
|EU  infrastructure, broadly accepted &lt;br /&gt;
|Useful&lt;br /&gt;
|-&lt;br /&gt;
|27&lt;br /&gt;
|EDCI&lt;br /&gt;
|Not  stable/ under development &lt;br /&gt;
|Acceptable,  but subject to improvement&lt;br /&gt;
|Piloted&lt;br /&gt;
|&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Useful&lt;br /&gt;
|-&lt;br /&gt;
|28&lt;br /&gt;
|EES&lt;br /&gt;
|Not  stable/ under development &lt;br /&gt;
|Aligned  with national policies, yet to be aligned with the EU&lt;br /&gt;
|Concept&lt;br /&gt;
|Useful&lt;br /&gt;
|-&lt;br /&gt;
|29&lt;br /&gt;
|eTimeStamp&lt;br /&gt;
|Not  stable/ under development &lt;br /&gt;
|Completely  aligned with current EU policies &lt;br /&gt;
|Concept&lt;br /&gt;
|Recommended&lt;br /&gt;
|-&lt;br /&gt;
|30&lt;br /&gt;
|eDocument&lt;br /&gt;
|Not  stable/ under development &lt;br /&gt;
|Acceptable,  but subject to improvement&lt;br /&gt;
|Concept &lt;br /&gt;
|Discarded&lt;br /&gt;
|-&lt;br /&gt;
|31&lt;br /&gt;
|RPAM&lt;br /&gt;
|Implemented  and running&lt;br /&gt;
|Acceptable,  but subject to improvement&lt;br /&gt;
|Piloted &lt;br /&gt;
|Useful&lt;br /&gt;
|-&lt;br /&gt;
|32&lt;br /&gt;
|SMP/SML&lt;br /&gt;
|Cutting-edge &lt;br /&gt;
|Completely  aligned with current EU policies &lt;br /&gt;
|runs in production in EU  (one or more MS) &lt;br /&gt;
|Recommended&lt;br /&gt;
|-&lt;br /&gt;
|33&lt;br /&gt;
|IMI&lt;br /&gt;
|Cutting-edge &lt;br /&gt;
|Completely  aligned with current EU policies &lt;br /&gt;
|EU  infrastructure, broadly accepted &lt;br /&gt;
|Discarded&lt;br /&gt;
|}&lt;br /&gt;
Following is the analysis of the results from the overall assessment from the aspect of the pilots’ needs, the conceptual framework and the overall architectural principles. It is important to note that this is not the exhaustive set of gap analysis, but it serves as a proof of concept for the methodological and assessment choices decisions made. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Pilots needs’ considerations'''&lt;br /&gt;
&lt;br /&gt;
From the table above, it can be noted that, although some of the BB are assessed as immature from some aspect, the final recommendation is still for them to be used by the pilots. This is due to the fact that, regardless of the current state of maturity, when matched with the pilots’ requirements, some a BB may still have the necessary architecture capabilities that require adjustment in the DE4A context. For instance, this is the case with SEMPER. The SEMPER extension to eIDAS is not fully mature yet but is the only cross-border functionality for working with proxies that currently mandates successfully piloted. Otherwise, there will be a need to develop a DE4A-specific solution for cross-border powers validation from the scratch, which is bot not useful and not feasible within the project timeframe. In order for SEMPER to gain a broader user-base, it has to be validated by more Member States (currently, it has been piloted with 4 MS). In addition, SEMPER has been piloted with legal persons only. Although this is sufficient to the DBA pilot, this is not the case for the moving abroad and studying abroad, as there is a need for piloting with natural persons. The DE4A pilots themselves may be used for this. Finally, SEMPER extends eIDAS, but has not been handed over to DIGIT yet. Therefore, it has not been incorporated in the eIDAS reference software of DIGIT yet. Integration in eIDAS will improve sustainability of the SEMPER extension. Concretely, SEMPER would benefit from eIDAS-like specifications to allow Member States that do not use the eIDAS reference software to develop their own extension based on these specifications. &lt;br /&gt;
&lt;br /&gt;
In contrast to SEMPER, there is also a case where a BB may be assessed as completely mature in most of the aspects but is still disregarded at the Recommendations stage. This is, for instance, the case with the IMI BB, which despite the overall high maturity in all aspects is out of the scope of the DE4A project. Similarly, the BRIS building block has a scope that is much narrower (especially from an administrative perspective) than the scope of DE4A and is therefore not to be used by the pilots. More concretely, BRIS has been developed for inter-business register communication, which is not the primary focus of the DBA pilot (the functional shortcomings on BRIS for piloting in DBA (D4.5, annex V) have been confirmed by DG DIGIT and there is no BRIS-roadmap foreseen that will deliver a solution to the findings). Furthermore, it is legally not feasible to use the BRIS-network for the DE4A-pilots (currently not allowed for non-business registers). An alternative is being discussed with DIGIT: a message broking platform as a possible future BRIS-wide solution that is piloted in TOOP. However, funding for continuation of the platform is not arranged and the current intention is to bring the (cloud-based) prototype infrastructure down when TOOP testing ends.&lt;br /&gt;
&lt;br /&gt;
Similar reasoning in compiling the overall recommendation score is applied to the other building blocks. These considerations have been discussed in detail at the BB Assessment Group meetings during the Recommendation step of the empirical framework. It is out of scope of the deliverable to present a detailed overview of each BB. However, the subtlety of some of the assessment criteria (such as context dependence) is also an argument to justify the decision to rely only on the experts’ evaluations in the first phase of the methodology.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Assessment outcomes considerations'''&lt;br /&gt;
&lt;br /&gt;
Out of the 33 assessed BB, 13 BB are Recommended for implementation, 9 are Acceptable, 7 are Useful and 4 are Discarded. From a maturity point of view: in terms of technical maturity, 5 are cutting-edge, 18 are implemented and running in an operational environment, whereas 10 are not stable or under development. From an administrative maturity aspect, almost half (17) of the BB are completely aligned with current EU policies; 7 are aligned with national policies but are yet to be consolidated at an EU level, whereas 9 (although acceptable) are still subject to further improvements. &lt;br /&gt;
[[File:Taxonomy of assessed BB with their recommendations .png|alt=Taxonomy of assessed BBs with their recommendations |center|frame|Taxonomy of assessed BB with their recommendations ]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
From operational maturity aspect, there are 8 BB which are broadly accepted as part of an EU infrastructure, 12 that run in production in one or more Member States and 10 that are piloted within some kind of operational or testing environment. It is interesting to note that the only aspect by which a BB has been assessed as immature is the Operational aspect. Thus, there are 4 BB (TOOD EDM, EES, eTimeStamp and eDocument) that are marked as operationally immature, as they are only at the stage of a Concept and are yet to be developed.&lt;br /&gt;
&lt;br /&gt;
From a BB type aspect (also visible in the figure above), most of the recommended BB are of the type ‘Building Block’ (7 out of 13) and ‘Standards and specifications’, whereas the ‘General services’ and the ‘Core service platforms’ are the least numerous and the most immature. This is expected, as the later are also the most complex ones and only few in number across EU. &lt;br /&gt;
&lt;br /&gt;
It is also notable that most of the BB considered for use by the pilots are in a mature and useful state that allows reusability and potential upgrades before implementation in the DE4A pilots. Such considerations are already being made (as discussed in the previous subsection) and are part of the piloting requirements to be assessed in the second phase of the methodology. &lt;br /&gt;
&lt;br /&gt;
'''Architecture framework considerations'''&lt;br /&gt;
&lt;br /&gt;
As outlined in the methodological considerations above, the two phases of the overall methodology follow the Enterprise Architecture Assessment Framework principles, with the additional step of providing recommendations for the pilot in between the two phases. Such an approach allows, in addition to the qualitative evaluation, to obtain e quantitative score for the maturity of the overall architecture as a (sub)set of the assessed BB. In that sense, while the output of the EAAF is a maturity level assessment of the overall architecture, the phased approach in DE4A creates an intermediate feedback loop between the pilots and the Project Start Architecture, allowing for adaptable integration of the assessment methodology within the WP2 change management.&lt;br /&gt;
&lt;br /&gt;
Regardless of the incomplete overall assessment, it is still possible to have a quantitative assessment for a solution architecture after the first assessment phase. However, this is not to be considered as the overall architecture framework maturity level, but only as a ‘current maturity level’ of the solution architecture comprised of a given set of BB. Such value can serve as a reference point to be compared upon a given KPI for the overall maturity, in case there is such requirement.&lt;br /&gt;
&lt;br /&gt;
In order to compile a single value for the current maturity level for a pilot solution architecture, the set of BB assessments and their recommendations shall be compared upon the baseline for the EAAF maturity levels.&lt;br /&gt;
[[File:EAAF Maturity levels.png|alt=EAAF Maturity levels|center|frame|EAAF Maturity levels]]&lt;br /&gt;
In the context of DE4A, we will provide such assessment in the second phase of implementation of this methodology, as currently there is no definite list of BB matched to the specific pilots.&lt;/div&gt;</summary>
		<author><name>Ictu mavi.cristache</name></author>
	</entry>
	<entry>
		<id>https://wiki.de4a.eu/index.php?title=File:EAAF_Maturity_levels.png&amp;diff=2998</id>
		<title>File:EAAF Maturity levels.png</title>
		<link rel="alternate" type="text/html" href="https://wiki.de4a.eu/index.php?title=File:EAAF_Maturity_levels.png&amp;diff=2998"/>
		<updated>2021-07-15T16:17:55Z</updated>

		<summary type="html">&lt;p&gt;Ictu mavi.cristache: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;EAAF Maturity levels&lt;/div&gt;</summary>
		<author><name>Ictu mavi.cristache</name></author>
	</entry>
	<entry>
		<id>https://wiki.de4a.eu/index.php?title=File:Taxonomy_of_assessed_BB_with_their_recommendations_.png&amp;diff=2997</id>
		<title>File:Taxonomy of assessed BB with their recommendations .png</title>
		<link rel="alternate" type="text/html" href="https://wiki.de4a.eu/index.php?title=File:Taxonomy_of_assessed_BB_with_their_recommendations_.png&amp;diff=2997"/>
		<updated>2021-07-15T16:15:44Z</updated>

		<summary type="html">&lt;p&gt;Ictu mavi.cristache: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Taxonomy of assessed BBs with their recommendations&lt;/div&gt;</summary>
		<author><name>Ictu mavi.cristache</name></author>
	</entry>
</feed>