Second phase - Revision history

Ictu harold.metselaar at 09:48, 3 February 2023

2023-02-03T09:48:14Z

Ictu harold.metselaar: /* Patterns */

2023-02-02T14:07:26Z

Patterns

Ictu harold.metselaar: /* Patterns */

2023-02-02T14:06:53Z

Patterns

Ictu harold.metselaar: /* Methodology */

2023-02-02T14:04:44Z

Methodology

Ictu harold.metselaar: /* Trust, Identity, Security, Privacy, Protection */

2023-02-02T13:56:44Z

Trust, Identity, Security, Privacy, Protection

Ictu harold.metselaar: /* Meeting pilot requirements */

2023-02-02T12:43:32Z

Meeting pilot requirements

Ictu harold.metselaar: /* Meeting pilot requirements */

2023-02-02T12:38:26Z

Meeting pilot requirements

Ictu harold.metselaar: /* Methodology */

2023-02-02T12:35:49Z

Methodology

Ictu harold.metselaar: /* Methodology */

2023-02-02T12:33:29Z

Methodology

Ictu harold.metselaar at 17:50, 31 January 2023

2023-01-31T17:50:30Z

← Older revision		Revision as of 09:48, 3 February 2023
Line 1:		Line 1:
−	~~== Under construction! ==~~
−
	== Building Block Assessment - 2nd Phase ==		== Building Block Assessment - 2nd Phase ==
	The second phase of the assessment of the architecture building blocks (BBs) used in the DE4A project comes after the cataloging of an initial set of relevant BBs for the Project Start Architecture (PSA). While in the previous phase the BBs were assessed for their technical, administrative and operational maturity, in this phase a more constrained set of BBs actually implemented by the pilots was evaluated from a wider perspective.		The second phase of the assessment of the architecture building blocks (BBs) used in the DE4A project comes after the cataloging of an initial set of relevant BBs for the Project Start Architecture (PSA). While in the previous phase the BBs were assessed for their technical, administrative and operational maturity, in this phase a more constrained set of BBs actually implemented by the pilots was evaluated from a wider perspective.

@@ Line 614: / Line 614: @@
 Some of the building blocks are used only for specific interaction patterns, while others span multiple patterns. In this section, we analyze the correlation between DE4A patterns and each of the 13 BBs, per pilot.
 As Figure 11 <span lang="EN">In terms of overall performance of each building block in
-the context of DE4A, </span> shows, the most employed is the User Supported Intermediation, closely followed by Verifiable Credential, whereas the least used are the Push [1] and Business patterns. However, this does not imply that these patterns are less useful, but only that they were exploited to a lesser extent in the DE4A depending on the pilots’ needs. For more documentation and guidelines on when and how each of these patterns can be used and implemented, please see the relevant pilot wiki.
+the context of DE4A, </span> shows, the most employed is the User Supported Intermediation, closely followed by Verifiable Credential, whereas the least used are the Push and Business patterns. However, this does not imply that these patterns are less useful, but only that they were exploited to a lesser extent in the DE4A depending on the pilots’ needs. For more documentation and guidelines on when and how each of these patterns can be used and implemented, please see the relevant pilot wiki.
 S&N and LKP are used in DBA but should also be applicable to non-business context

@@ Line 613: / Line 613: @@
 === Patterns ===
 Some of the building blocks are used only for specific interaction patterns, while others span multiple patterns. In this section, we analyze the correlation between DE4A patterns and each of the 13 BBs, per pilot.
-As Figure 11<span lang="EN">In terms of overall performance of each building block in
+As Figure 11 <span lang="EN">In terms of overall performance of each building block in
 the context of DE4A, </span> shows, the most employed is the User Supported Intermediation, closely followed by Verifiable Credential, whereas the least used are the Push [1] and Business patterns. However, this does not imply that these patterns are less useful, but only that they were exploited to a lesser extent in the DE4A depending on the pilots’ needs. For more documentation and guidelines on when and how each of these patterns can be used and implemented, please see the relevant pilot wiki.
 ----This is apprently the deregistration thing?

@@ Line 8: / Line 8: @@
 * Member States (MSs)
-* WP4 partners - Pilots (Doing Business Abroad - DBA, Moving Abroad - MA, and Studying Abroad - SA)
+* WP4 partners - Pilots ([[Doing Business Abroad Pilot|Doing Business Abroad - DBA]], [[Moving Abroad Pilot|Moving Abroad - MA]], and [[Studying Abroad Pilot|Studying Abroad - SA]])
 * WP5 partners - for specific components
@@ Line 180: / Line 180: @@
 Of the new requirements[1], the following were noted:
 * Those necessary to define and implement the above functionalities;
-* SSI authority agent and SSI mobile agent were updated to simplify the SA UC3 ("Diploma/Certs/Studies/Professional Recognition") service;
+* SSI authority agent and SSI mobile agent were updated to simplify the [[Use Case "Diploma/Certs/Studies/Professional Recognition" (SA UC3)|SA UC3 ("Diploma/Certs/Studies/Professional Recognition")]] service;
 * Subscription and Notification pattern, Evidence Request, DE/DO mocks (see project’s wiki solution architecture iteration 2, for requirements regarding Subscription and Notification); and
 * Deregistration.

@@ Line 633: / Line 633: @@
 Most of the issues are related to security and are introduced as a result of record matching and difficulties with certificates. The small amount of privacy issues is related to data protection, and mainly refer to the usage of eDelivery and 4 corner model during piloting.
-The issues stated as being introduced by the use of the BB (on Figure 13b)) mainly refer to availability and connectivity, and are related to the use of certificates. However, these issues are not due to the BB nature or the lack of some functionality, but a result of the absence of improvements that were needed to meet the implementation requirements. Thus, this does not affect the reuse aspect of any of the assessed BBs.
+The issues stated as being introduced by the use of the BB (on Figure 13b)) mainly refer to availability and connectivity and are related to the use of certificates. However, these issues are not due to the BB nature or the lack of some functionality, but a result of the absence of improvements that were needed to meet the implementation requirements. Thus, this does not affect the reuse aspect of any of the assessed BBs.
 In order to analyze in a greater depth, the security issues encountered, the survey inquired on the security mechanisms available to handle and address such issues in terms of confidentiality, integrity and availability, as well as the BB features used for that purpose. The cases in which concrete BB features were employed to address security issues are presented in the charts of Figure 14, a), b) and c).
-[[File:BB features used to address .png|none|thumb]]
+[[File:BB features used to address .png|none|thumb|Figure 14. a) Confidentiality]]
-[[File:Confidentiality.png|none|thumb]]
+[[File:Confidentiality.png|none|thumb|Figure 14. b) Integrity]]
-[[File:Availability.png|none|thumb]]
+[[File:Availability.png|none|thumb|Figure 14. c) Availability]]
@@ Line 648: / Line 648: @@
 In most (80%) of the cases, the security mechanisms were used to counter specific cyber threats (Figure 15a)). In half of these, the vulnerabilities to a cyber-attack were introduced by the employed BBs (or their features) (Figure 15b)).
-[[File:Extent of employing security mechanisms to counter specific cyber-threats.png|none|thumb]]
+[[File:Extent of employing security mechanisms to counter specific cyber-threats.png|none|thumb|Figure 15. a). Extent of employing security mechanisms to counter specific cyber-threats]]
-[[File:Frequency of BBs introducing new vulnerabilities.png|none|thumb]]
+[[File:Frequency of BBs introducing new vulnerabilities.png|none|thumb|Figure 15. b) Frequency of BBs introducing new vulnerabilities]]
 Features claimed to introduce such vulnerabilities are some libraries, and only at a certain point of the piloting (such as log4j and the spring framework). However, these vulnerabilities were detected and fixed on time. Other vulnerabilities that were also met and addressed were DoS and increased risk of data hijacking. To address these vulnerabilities, adequate countermeasures have been employed, such as: access control, channel encryption, authentication and digital signatures. For example, all communications have been secured via the use of certificates, so that the communications are encrypted. In addition, the components of the playground have been deployed using redundancy.
@@ Line 655: / Line 655: @@
 In the first phase of the BB assessment, we used the Digital Services Model taxonomy to establish common terminology and framework, but also to analyze the needs and requirements for the deployment of the digital services in DE4A. The overall purpose of such an approach is enabling a continuity of the developed methodologies with the large-scale pilots. This taxonomy contained five different levels of granularity:
-# Standards     and Specifications;
+# Standards and Specifications;
-# Common code     or Components;
+# Common code or Components;
-# Building     Blocks;
+# Building Blocks;
-# Core Service     Platforms;
+# Core Service Platforms;
 # Generic Services.
@@ Line 666: / Line 666: @@
 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 given in Figure 16. In the context of DE4A, based on the maturity evaluations provided in the section on “BB Maturity”, it can be observed that most of the BBs and their functionalities, implementation details and operation in the context of DE4A have been documented, understood, and used in at least some agency of decision-making activities. However, from the “Performance and Non-Functional Requirements” Section, we see that not all have gone through an effectiveness evaluation against a set of established performance criteria. Thus, '''the level of maturity of the overall set of DE4A architecture BBs according to the EAAF is 3.'''
-[[File:EAAF Maturity levels.png|none|thumb]]
+[[File:EAAF Maturity levels.png|none|thumb|Figure 16. EAAF Maturity levels]]
 = Conclusion =

@@ Line 563: / Line 563: @@
 |}
 Figure 8 further details the level of criticality of the listed barrier in the context of DE4A.
-[[File:Level of criticality of the barriers from Table 6 for DE4A.png|none|thumb]]
+[[File:Level of criticality of the barriers from Table 6 for DE4A.png|none|thumb|Figure 8. Level of criticality of the barriers from Table 6 for DE4A]]
 All types of barriers have had elements of high criticality to be addressed, although the technical barriers had the highest criticality during implementation. These were mainly related to the need of knowing different external technologies and protocols in a very short time, such as in the case of eDelivery, but also to maintainability and sustainability of certain regulatory requirements related to technical implementation. High accent for all types of barriers was put on the time-frames needed to meet certain requirements, which were often in discord with the technical readiness of the current infrastructure and the human ability to respond to the required changes. Finally, the amount of available resources was present in all barriers - in terms of scarce human resources, technical expertise, administrative procedures, legislative readiness, infrastructure and staff availability, etc.
@@ Line 570: / Line 570: @@
 In that sense, Figure 9 shows the importance of each of these aspects (legal, organizational, technical, semantic, business, political and human factors) in the context of DE4A. In other words, the responding partners articulated the aspects that appeared as most important in their experience with piloting and implementation. The assessed BBs have mainly performed satisfactory across all dimensions, and even exceeded expectations on some technical and semantic traits. However, there is a (small) subset of traits across most dimensions on which the BBs also underperformed. These mainly refer to the barriers and the unmet requirements discussed earlier in this analysis. Some of them are also enlisted later in this section.
-[[File:Importance of each BB aspect (dimension) for DE4A.png|none|thumb]]In terms of overall performance of each building block in the context of DE4A, Figure 10 shows that the only BB who was claimed as '''Underperforming''' is IAL, which we also pin-pointed in the maturity analysis as well, in each of the Technical, Administrative and Operational aspects.
+[[File:Importance of each BB aspect (dimension) for DE4A.png|none|thumb|Figure 9. Importance of each BB aspect (dimension) for DE4A]]In terms of overall performance of each building block in the context of DE4A, Figure 10 shows that the only BB who was claimed as '''Underperforming''' is IAL, which we also pin-pointed in the maturity analysis as well, in each of the Technical, Administrative and Operational aspects.
-[[File:Overall performance of each building block in the context of DE4A.png|none|thumb]]
+[[File:Overall performance of each building block in the context of DE4A.png|none|thumb|Figure 10. Overall performance of each building block in the context of DE4A]]
 Although there are no specific non-functional requirements (NFRs) with respect to performance, availability and scalability, and no performance tests were performed for DE4A, the idea of this section is to get a perception of the partners’ experience with non-functional requirements in the context of DE4A. Table 1 provides an overview of the partners’ claims.
 {| class="wikitable"
 |'''Type of NFR issue'''
 |'''Encountered'''
@@ Line 619: / Line 619: @@
 S&N and LKP are used in DBA but should also be applicable to non-business context
-[[File:Overall use of DE4A patterns.png|none|thumb]]
+[[File:Overall use of DE4A patterns.png|none|thumb|Figure 11. Overall use of DE4A patterns]]
 The use of each of these patterns per building block is shown in Figure 12.
-[[File:Use of each pattern by each building block.png|none|thumb]]
+[[File:Use of each pattern by each building block.png|none|thumb|Figure 12. Use of each pattern by each building block]]
 === Trust, Identity, Security, Privacy, Protection ===
 There are various trust models in use in DE4A, depending on the interaction patterns used. All those patterns come with specifics related to authentication/establishing identity, security controls and possible privacy issues. This applies to both data at rest/in transfer. Figure 13a) shows the nature and the amount of the specific security/privacy issues encountered during implementation.
-[[File:Security and privacy issues encountered.png|none|thumb]]
+[[File:Security and privacy issues encountered.png|none|thumb|Figure 13. a) Security and privacy issues encountered]]
-[[File:No. of issues due to the BB use.png|none|thumb]]
+[[File:No. of issues due to the BB use.png|none|thumb|Figure 13. b) # of issues due to the BB use]]

@@ Line 133: / Line 133: @@
 == Data and preprocessing ==
 After the data gathering period, a total of 10 surveys were received with valid input, representing full coverage of the BBs by foreseen parties (See Table 2). This provides sufficient statistical significance to proceed with the analysis of the results and finalize the BB assessment.
 {| class="wikitable"
-|+Table 4. Recommendations for use and implementation of the BBs
+|+Table 2.Distribution of received valid feedback per partner type
 |'''Partner type'''
 |'''# of assessments done'''
@@ Line 249: / Line 247: @@
 Finally, half of the BBs were also marked as sector-specific. Thus, some are only relevant for public administrations, others for certain education environments (e.g., canonical data models in the SA pilot are specific to higher education), and some - for the business domain.
 {| class="wikitable"
 |+Table 3. BB usability traits in the context of DE4A
@@ Line 376: / Line 372: @@
 |}
 As a result of these experiences, practical recommendations for use and implementation of the BBs are also provided (see Table 4 below), together with pointers to some of the successful uses in the context of DE4A.
 {| class="wikitable"
 |+Table 4. Recommendations for use and implementation of the BBs
@@ Line 437: / Line 431: @@
 After BBs piloting implementation, we asked pilot partners to also document their experience in terms of BBs meeting the initial requirements for the particular piloting context. These experiences are listed in Table 5, which shows that most of the piloting requirements were met, although for some of the BBs new functionalities were provided (as discussed in the first subsection of this analysis) in order to achieve the piloting objectives.
 {| class="wikitable"
 |'''#'''
 |'''Building Block'''
@@ Line 520: / Line 514: @@
 |}
 As the barriers to meeting piloting requirements and smooth implementation may be of different nature, we have analyzed them in a finer granularity. This systematization of barriers has been rationed and defined in WP1, and can be found in Deliverable 1.8 – “Updated legal, technical, cultural and managerial risks and barriers”. Table 6, provides the partners experiences in terms of implementation barriers, describing them in the context in which they were encountered.
 {| class="wikitable"
 |'''Type of barrier'''
 |'''Description of barrier'''

@@ Line 176: / Line 176: @@
 * Deregistration, multi evidence.
-[[File:New functionalities.png|left|thumb]]
+[[File:New functionalities.png|thumb|alt=|none|Figure 1. a) New functionalities]]
-[[File:New requirements.png|thumb|239x239px]]
+[[File:New requirements.png|thumb|239x239px|alt=|none|Figure 1. b) New requirements for the existing BBs defined in DE4A lifetime]]
 Of the new requirements[1], the following were noted:
 * Those necessary to define and implement the above functionalities;
 * SSI authority agent and SSI mobile agent were updated to simplify the SA UC3 ("Diploma/Certs/Studies/Professional Recognition") service;
@@ Line 228: / Line 213: @@
 Furthermore, Figure 3a) provides insight into the potential of each BB to contribute to interoperability in contexts other than DE4A, while Figure 3b) depicts the contribution of the analyzed BBs per each interoperability dimension, in general. It is important to note that this latter analysis (of the BBs potential) also takes into account the additional functionalities of the BBs defined during DE4A lifespan, through their piloting, and with the updated set of requirements. Thus, these figures also provide a proof of the DE4A contribution in the improvement of BB potential to respond to a wider set of interoperability requirements along each of the four dimensions: Legal, Organization, Semantic and Technical.
-[[File:Contribution of each BB.png|thumb|alt=|none]]
+[[File:Contribution of each BB.png|thumb|alt=|none|Figure 2. a) Contribution of each BB to interoperability in the context of DE4A]]
-[[File:Contribution per interoperability dimension..png|none|thumb]]
+[[File:Contribution per interoperability dimension..png|none|thumb|Figure 2. b) Contribution per interoperability dimension]]
-[[File:Potential for contribution of each BB.png|none|thumb]]
+[[File:Potential for contribution of each BB.png|none|thumb|Figure 3. a) Potential for contribution of each BB to interoperability; b) Potential for contribution per interoperability dimension]]
-[[File:Potential for contribution per interoperability dimension.png|none|thumb]]
+[[File:Potential for contribution per interoperability dimension.png|none|thumb|Figure 3. b) Potential for contribution per interoperability dimension.]]Finally, as part of the analysis of BB interoperability, the survey asked the relevant partners to indicate if a BB could help enable other technologies or standards. In that sense, the DE4A-VC pattern makes use of a Wallet, which could be an enabler for the EUDI Wallet. Moreover, it was also denoted as having the potential for reuse in order to enable take up of EBSI. Furthermore, the DBA pilot makes use of SEMPER, which could facilitate the adoption and spreading of SEMPER as a standard for authentication and powers/mandates. Finally, the CompanyEvidence model could be used as evidence standard with implementation of SDG OOTS.
 === BB Maturity ===
-In the first phase of the BB assessment, domain experts provided qualitative assessment of the maturity of the BB along the following dimensions:
+In the [[Building Blocks|first phase of the BB assessment]], domain experts provided qualitative assessment of the maturity of the BB along the following dimensions:
 .   Technical
@@ Line 248: / Line 230: @@
 The following scale was used to provide input on the level of maturity of the given set of BBs by each relevant partner: 0 - Discarded; 1 - Useful, 2 - Acceptable, 3 - Recommended). This is the identical scale employed for the assessment of the BBs in the first phase. As a reference, the semantics behind these scores is also again given here on Figure 4 below.
-[[File:Grading semantics of the evaluation scores used in the first and the second phase.png|none|thumb]]
+[[File:Grading semantics of the evaluation scores used in the first and the second phase.png|none|thumb|Figure 4. Grading semantics of the evaluation scores used in the first and the second phase]]
 However, there is one important aspect on which the BB assessment in this phase differs from the previous. Whereas previously we obtained a single evaluation score to determine the general maturity of a BB, in the current iteration, the 13 BBs were evaluated for each type of maturity (Technical, Administrative, Operational). This is actually fine-tuning of the initial methodology, which appeared insufficiently granular to provide correct output. Due to this lack of granularity and the inability to capture some contextual specificities, in the first phase the SEMPER building block was denoted as '''Immature''', but was still '''Recommended''' for use in the DE4A.
-As Figure 5 below show, none of the 13 BBs analyzed in this phase was '''Discarded''' for future implementation and reuse. The highest level of maturity was achieved Administrative context, where almost half of the BBs are considered to be completely aligned with current EU policies and only one BB (IAL) is denoted as unstable. From a technical maturity aspect, most of the BBs are implemented and running, while 2 (IAL and MOR) are still unstable and under development. Similar is the case with operational maturity, where 3 BBs are deemed as unstable: SMP/SML[1] , IAL and MOR. Hence, it is reasonable to pinpoint IAL as the least mature BB, which is however not to be discarded for reuse and re-uptake by other projects.
+As Figures 5. a,b and c below show, none of the 13 BBs analyzed in this phase was '''Discarded''' for future implementation and reuse. The highest level of maturity was achieved Administrative context, where almost half of the BBs are considered to be completely aligned with current EU policies and only one BB (IAL) is denoted as unstable. From a technical maturity aspect, most of the BBs are implemented and running, while 2 (IAL and MOR) are still unstable and under development. Similar is the case with operational maturity, where 3 BBs are deemed as unstable: SMP/SML[1] , IAL and MOR. Hence, it is reasonable to pinpoint IAL as the least mature BB, which is however not to be discarded for reuse and re-uptake by other projects.
-[[File:Technical.png|none|thumb]]
+[[File:Technical.png|none|thumb|Figure 5. a) Technical Maturity of BB]]
-[[File:Administrative.png|none|thumb]]
+[[File:Administrative.png|none|thumb|Figure 5. b) Administrative Maturity of BB]]
-[[File:Operational.png|none|thumb]]
+[[File:Operational.png|none|thumb|Figure 5. c)Operational Maturity of BB]]
 Figure 6 provides insight into the general state of maturity of each of the BBs, showing that each of the 13 building blocks integrates all aspects of maturity in its overall maturity. Furthermore, the figure also makes it evident that some of the BBs are more advanced in one aspect and less in others. For instance, the DE4A Playground demonstrates higher technical maturity, whereas its operational maturity has been reached to a lesser extent. Similarly, MOR’s maturity is mainly in administrative sense, and to a lesser extent in the technical and operational sense.
-[[File:General state of maturity of each BBs.png|none|thumb]]
+[[File:General state of maturity of each BBs.png|none|thumb|Figure 6. General state of maturity of each BBs]]
 === BB Openness ===
 In this section, we analyzed the openness of each of the 13 BBs along several dimensions, i.e. properties: Extensibility, Customizability and Modularity. As Figure 7 shows, the most prevalent of all is ''Extensibility'', present in most of the BB except the SSI User and Authority agent. Most of the BBs lend themselves to Customization, and more than half are also modular.
-[[File:Properties enabling building block openness.png|none|thumb]]
+[[File:Properties enabling building block openness.png|none|thumb|Figure 7. Properties enabling building block openness]]
 It is important to note, however, that 75% of the partners stated that the implementation, i.e. the use of some of the BBs is either technology, platform or solution dependent. For instance, IEM is DE4A specific, while CompanyData model is usable beyond DE4A. Furthermore, many components depend on a one-man company, introducing risks in terms of support and maintenance. Similarly, EBSI and federated services were denoted as solution/platform dependent, especially in the context of mixed environments .
@@ Line 269: / Line 251: @@
 Table 3. BB usability traits in the context of DE4A
 {| class="wikitable"
 |'''#'''
 |'''Building Block'''

← Older revision		Revision as of 17:50, 31 January 2023
Line 670:		Line 670:

	In most (80%) of the cases, the security mechanisms were used to counter specific cyber threats (Figure 15a)). In half of these, the vulnerabilities to a cyber-attack were introduced by the employed BBs (or their features) (Figure 15b)).		In most (80%) of the cases, the security mechanisms were used to counter specific cyber threats (Figure 15a)). In half of these, the vulnerabilities to a cyber-attack were introduced by the employed BBs (or their features) (Figure 15b)).
		+	[[File:Extent of employing security mechanisms to counter specific cyber-threats.png\|none\|thumb]]
		+	[[File:Frequency of BBs introducing new vulnerabilities.png\|none\|thumb]]
		+	Features claimed to introduce such vulnerabilities are some libraries, and only at a certain point of the piloting (such as log4j and the spring framework). However, these vulnerabilities were detected and fixed on time. Other vulnerabilities that were also met and addressed were DoS and increased risk of data hijacking. To address these vulnerabilities, adequate countermeasures have been employed, such as: access control, channel encryption, authentication and digital signatures. For example, all communications have been secured via the use of certificates, so that the communications are encrypted. In addition, the components of the playground have been deployed using redundancy.
		+
		+	= Discussion and comparative analysis =
		+	In the first phase of the BB assessment, we used the Digital Services Model taxonomy to establish common terminology and framework, but also to analyze the needs and requirements for the deployment of the digital services in DE4A. The overall purpose of such an approach is enabling a continuity of the developed methodologies with the large-scale pilots. This taxonomy contained five different levels of granularity:
		+
		+	# Standards and Specifications;
		+	# Common code or Components;
		+	# Building Blocks;
		+	# Core Service Platforms;
		+	# Generic Services.
		+
		+	Most of the recommended BBs in the first phase were of the type ‘Building Block’ and ‘Standards and specifications’. However, this is also expected and is not an argument against maturity, as these are also the elements/components that are most flexible in terms of configurability and deployment and, thus, most subject to reuse by other projects. In order to provide arguments for the overall set of building blocks assessed for DE4A purposes, we will rely on the Enterprise Architecture Assessment Framework principles (shown in Figure 16), also presented in the first phase of BB assessment.
		+
		+	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. Although for the evaluation of the overall PSA additional insights are needed, it is still possible to obtain some quantitative assessment for the solution architecture based on the set of employed BBs. However, it is important to note that this is not to be considered as the overall architecture framework maturity level, but only as an aspect of it that provides valid arguments for discussion on the overall maturity. For instance, such a value can serve as a reference point that can be compared upon a given KPI for the overall maturity, in case such a requirement exists.
		+
		+	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 given in Figure 16. In the context of DE4A, based on the maturity evaluations provided in the section on “BB Maturity”, it can be observed that most of the BBs and their functionalities, implementation details and operation in the context of DE4A have been documented, understood, and used in at least some agency of decision-making activities. However, from the “Performance and Non-Functional Requirements” Section, we see that not all have gone through an effectiveness evaluation against a set of established performance criteria. Thus, '''the level of maturity of the overall set of DE4A architecture BBs according to the EAAF is 3.'''
		+	[[File:EAAF Maturity levels.png\|none\|thumb]]
		+
		+	= Conclusion =
		+	In this analysis, we presented the second phase of a 2-phased approached for building blocks assessment used in the DE4A project. The entire approach followed a concrete methodology designed in the initial stages of the project start architecture, and updated/fine-tuned during the piloting of the building blocks. The first assessment phase resulted in a list of BBs relevant and recommended for use in the DE4A based on three aspects of their maturity: Technical, Administrative and Operational. Both the definition and the fine-tuning of the methodology, as well as the updating of the list of relevant BBs was done in close collaboration with the relevant DE4A implementing and using the BBs: WP4 (pilots) partners, the Member States, and WP4 (components) partners.
		+
		+	During the second phase, 13 BBs were analyzed from a wider perspective, i.e. for their interoperability (across each EIF/EIRA dimension), maturity (across the three dimensions used in the first phase as well), openness (across three dimensions), usability (across three dimensions), meeting pilot requirements, performance and non-functional requirements (across 7 dimensions), patterns’ use, as well as for addressing trust, identity, security and privacy issues in the context of DE4A. Moreover, barriers for implementation were detected of various nature: technical, business, legal, organizational, political, semantic and human factor. Based on the insights from the obtained feedback, and the direct partners’ experiences, recommendations for future (re)use were also provided as part of the analysis.
		+
		+	On the one side, this effort complements the other architecture tasks carried out in the DE4A, supporting the design choices on the PSA. On the other side, it testifies of the effective internal collaboration among a variety of DE4A partners. Finally, the approach serves as a documented effort of reusable practices and solutions provided through the DE4A partners’ experiences.