DESCRIPTION: A business capability is the ability of a public administration to digitally perform an administrative function. Based on the definitions from the European Statistical System: https://joinup.ec.europa.eu/collection/statistical-enterprise-architecture/document/ess-earf-business-capabilities-model INTEROPERABILITY SALIENCY: Not applicable EXAMPLES: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): ePrescription: "Generation, transmission, and filling of a medical prescription through digital channels. ePrescribing allows a physician, pharmacist, nurse practitioner, or physician assistant to use digital prescription software to electronically transmit a new prescription or renewal authorization to a community or mail-order pharmacy". Definition: Digital Business Capability ABB is a Capability, that corresponds to an ability implemented in a system to enable a public administrations to perform an administrative function. Source: European Statistical System Source reference: https://joinup.ec.europa.eu/collection/statistical-enterprise-architecture/document/ess-earf-business-capabilities-model Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/DigitalBusinessCapabilityCapability LOST view: Organisational view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:DigitalBusinessCapabilityCapability Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): ePrescription: "Generation, transmission, and filling of a medical prescription through digital channels. ePrescribing allows a physician, pharmacist, nurse practitioner, or physician assistant to use digital prescription software to electronically transmit a new prescription or renewal authorization to a community or mail-order pharmacy". Interoperability Saliency: Digital Business Capability ABB is salient for organizational interoperability because it determines the core business functions and operations of public administration services. This ABB ensures the coordination of public systems to make a response to specific procedures. Additional information: The Digital Business capability enable public administations to performadministrative functions inthe framework of e-governance. Interoperability Dimension: Structural IoP Viewpoint: Highlevel viewpoint Additional identifier: http://data.europa.eu/dr8/DigitalBusinessCapabilityCapability EIF Layer: Organisational Definition: Public Policy ABB is a Course of Action allowing public authorities to bring social change in the medium and long term, in a given area. Source: EuroVoc Source reference: http://eurovoc.europa.eu/drupal/?q=request&concepturi=http%3A%2F%2Feurovoc.europa.eu%2F8466&termuri=http%3A%2F%2Feurovoc.europa.eu%2F209598&language=en&view=pt&ifacelang=en Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/PublicPolicyCourseOfAction LOST view: Legal view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:PublicPolicyCourseOfAction Synonym: Policy Action Example: The Common Agricultural Policy (CAP, https://ec.europa.eu/info/strategy/agriculture_en) is an example on how the Public Policy Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB). The common agricultural policy (CAP) – one of Europe’s oldest policies – has evolved along with the EU. Today's CAP supports a modern, market-oriented farming sector ensuring the provision of safe, affordable, high quality food, produced sustainably and respecting strict standards (environmental, animal welfare, food safety, etc.), as well as supporting investment in the broader rural economy. Interoperability Saliency: The Public Policy ABB  is salient for legal interoperability because it drives the production and formulation of legislation, and it is one of the main context elements to be taken into account when different organisations need to work together, as stated in the EIF: "Legal interoperability is about ensuring that organisations operating under different legal frameworks, policies and strategies are able to work together". Additional information: A Public Policy is based on certain values and objectives and is implemented using a variety of methods. It applies on the territory within which the authority is authorised to act.The policies overview of EU activities in all areas, from agriculture to transport: (http://ec.europa.eu/policies/index_en.htm) Interoperability Dimension: Structural IoP Viewpoint: Interoperability Security viewpoint Additional identifier: http://data.europa.eu/dr8/PublicPolicyCourseOfAction EIF Layer: Legal DEFINITION: Organisation ABB is a Business Actor providing and/or consuming Public Services as a principal. Source: EIF and the ISA2 Core Vocabularies (http://eur-lex.europa.eu/resource.html?uri=cellar:2c2f2554-0faf-11e7-8a35-01aa75ed71a1.0017.02/DOC_3&format=PDF) (https://joinup.ec.europa.eu/asset/cpov/asset_release/core-public-organisation-vocabulary-v100#download-links) Syn. Institution, body INTEROPERABILITY SALIENCY: IoP Dimension: Governance IoP The Organisation ABB is salient for organisation interoperability because organisations can play the role both of providers of Public Services (mainly Public Administrations) and consumers of Public Services (Public Administration or businesses), as stated in the EIF: "A European public service comprises any public sector service exposed to a cross-border dimension and supplied by public administrations, either to one another or to businesses and citizens in the Union." EXAMPLES: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): AFIS - Europol organisation Europol is the European Union’s law enforcement agency. Its main goal is to achieve a safer Europe for the benefit of all the EU citizens. Source: (https://www.europol.europa.eu/) DEFINITION: Public Service Agent ABB is a Business Actor consuming or delivering a public service on behalf of a principal. Source: Joinup (https://joinup.ec.europa.eu/rdf_entity/http_e_f_fdata_ceuropa_ceu_fw21_f7661a4a0_bbdf9_b4e98_bb04a_b967c6a1053f9) INTEROPERABILITY SALIENCY: IoP Dimension: Governance IoP The Public Service Agent is salient for organisational interoperability because it acts on behalf of a Public Service Consumer Agent to consume a Public Service and Public Service Provider Agent to deliver a Publice Service. EXAMPLES: Your Europe Advice – ECAS Your Europe Advice is an EU advice service provided by legal experts from ECAS (European Citizen Action Service) operating under contract with the European Commission. It consists of a team of about 60 lawyers who cover all 24 official EU languages and are familiar both with EU law and national laws in all EU countries. Your Europe Advice replies to questions from citizens or businesses on their personal EU rights. The experts respond to the questions within one week, free of charge and in the language chosen by the user. ECAS’ mission is to empower citizens to exercise their rights and promote open and inclusive decision-making through the provision of high quality advice, research and advocacy, as well as capacity building for civil society organisations. Source: (http://ecas.org/services/your-europe-advice-yea/) DEFINITION: Citizen ABB is a Business Actor providing and/or consuming Public Services. A citizen is a member of a particular country and who has rights because of being born there or because of being given rights. Every national of a Member State shall be a citizen of the Union. Citizenship of the Union shall be additional to national citizenship and shall not replace it (Treaty of Maastricht on European Union, Title II Provisions on democratic principles, article 8). The main difference between the two (European citizenship and citizenship of a Member State) is that the rights that citizens enjoy as a result of European citizenship are not matched with duties. Legal basis: Articles 9 to 12 TEU and 18 to 25 TFEU (European Parliament). The additional rights EU citizenship confers are detailed at http://ec.europa.eu/justice/citizen/index_en.htm (European Commission). Source: EUR-Lex, Europa web site and the Cambridge Dictionary (http://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=OJ:C:2007:306:FULL&from=EN) (http://www.europarl.europa.eu/atyourservice/en/displayFtu.html?ftuId=FTU_2.1.1.html) (http://dictionary.cambridge.org/dictionary/english/citizen) INTEROPERABILITY SALIENCY: IoP Dimension: Governance IoP The Citizen ABB is salient for organisation interoperability because citizens can play the role of consumers of Public Services, as stated in the EIF: "A European public service comprises any public sector service exposed to a cross-border dimension and supplied by public administrations, either to one another or to businesses and citizens in the Union." EXAMPLES: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): EUROPASS2 - EU citizen Every national of a Member State shall be a citizen of the Union. Source: (http://europass.cedefop.europa.eu/europass-and-you) DEFINITION: Public Administration ABB is a Business Actor providing public services as a state, regional or local authority governed by public law or an association formed by one or several such authorities or a private entity mandated by at least one of those authorities or associations. Source: Connecting Europe Facility (CEF), eIDAS regulation (https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/CEF+Definitions) Syn. Public institution, public body INTEROPERABILITY SALIENCY: IoP Dimension: Governance IoP The Public Administration ABB is salient for organisation interoperability because Public Administrations can play the role both of providers and consumers of Public Services, as stated in the EIF: "A European public service comprises any public sector service exposed to a cross-border dimension and supplied by public administrations, either to one another or to businesses and citizens in the Union." EXAMPLES: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): EWRS – ECHA The European Chemicals Agency (ECHA) is the driving force among regulatory authorities in implementing the EU's ground breaking chemicals legislation for the benefit of human health and the environment as well as for innovation and competitiveness. Source: (https://echa.europa.eu/about-us) DEFINITION: Business ABB is a Business Actor performing a private activity for a profit. Source: IATE (definition of business, entry Environment [CdT]) (http://iate.europa.eu/) Syn. Company INTEROPERABILITY SALIENCY: IoP Dimension: Governance IoP The Business ABB is salient for organisation interoperability because organisations can play the role of consumers of Public Services (Public Administration or businesses), as stated in the EIF: "A European public service comprises any public sector service exposed to a cross-border dimension and supplied by public administrations, either to one another or to businesses and citizens in the Union." EXAMPLES: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Healthcare institution: A Healthcare institution represents every place, institution, building or agency, whether organised for profit or not, which provides facilities with medical services, nursing services, health screening services, other health‐related services, supervisory care services, personal care services or directed care services. Source: (https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&cad=rja&uact=8&ved=2ahUKEwjBu7KRlMb2AhU8gP0HHR0xCtAQFnoECEMQAQ&url=https%3A%2F%2Fwww.sciencedirect.com%2Ftopics%2Fcomputer-science%2Fhealthcare-institution&usg=AOvVaw2TJc49cSdQbi9LGsOOCGl8) DESCRIPTION: A particular ability or capacity that an organisation may possess or exchange to achieve a specific purpose or outcome. Defining a business capability involves identifying and describing what needs to be done by the business in support of its overall mission. Business capabilities provide an abstraction of the business reality in a way that helps to simplify conversations between interested stakeholders. Based on TOGAF definition and description of business capability. https://www2.opengroup.org/ogsys/catalog/g161 Syn. Business Ability INTEROPERABILITY SALIENCY: IoP Dimension: Structural IoP, Behavioral IoP The Business Capability ABB  is salient for organisational interoperability because it defines the main business reason for exchanging business information with other business capabilities in another organisation or in the same organisation. EXAMPLES: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Surveillance3 reporting and generation of data sets The reporting and generation of data sets business capability brought by Surveillance3 enables the reporting and analysis of data by the end users, through integration mechanisms to other applications. Surveillance3 aggregates the declaration data and additional data such as Binding Tariff Information (BTI) decisions and Surveillance definitions in order to produce consolidated reports about: 1. The BTI usage for the DG TAXUD BTI sector users and for Member State users and 2. Surveillance statistical data http://ec.europa.eu/taxation_customs/dds2/surv/surv_consultation.jsp?Lang=en DESCRIPTION: Business capability on exchanging data, information, and Knowledge Based on TOGAF definitions. https://www2.opengroup.org/ogsys/catalog/g161 http://pubs.opengroup.org/architecture/togaf9-doc/arch/ (*)DECISION (EU) 2015/2240 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 25 November 2015 establishing a programme on interoperability solutions and common frameworks for European public administrations, businesses and citizens (ISA2 programme) as a means for modernising the public sector. Syn. Exchange of Business Facts, Exchange of Business Data, Exchange of Business Opinions INTEROPERABILITY SALIENCY: IoP Dimension: Structural IoP, Behavioral IoP The Exchange of business Information ABB is salient for interoperability because it helps achieve organisational interoperability by ensuring compatible interaction between organisations, as stated in the EIF: "For the purpose of the EIF, interoperability is the ability of organisations to interact towards mutually beneficial goals, involving the sharing of information and knowledge between these organisations, through the business processes they support, by means of the exchange of data between their ICT systems". EXAMPLES: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Easi-MicPro - Agreement of Code of good conduct Proof of transparency and usage of pan-European reporting standards. https://webgate.ec.europa.eu/easi-micpro/application#!cogcPublicPage DEFINITION: Service Delivery Mode ABB is a Business Interface delivering to public service consumers, or otherwise interacting with them, for the purpose of supplying specific public services with accessibility value. This involves a number of management practices to ensure that the public services are provided as agreed between the public service provider and the consumer. The service delivery mode should also ensure a constant and stable access to public service in alarm and crisis situations (e.g., COVID 19 pandemic, natural disasters, etc.). Here some examples of service delivery mode: i) Mobile App; ii) Web Portal; iii) Web Services; iv) Contact Center, etc. Source: Innovation Policy Platform (https://www.innovationpolicyplatform.org/printpdf/12406) INTEROPERABILITY SALIENCY: IoP Dimension: Behavioural IoP The Service Delivery Mode ABB is a key interoperability enabler because it supports to achieve organisational behavioral interoperability by enabling the exchange of data, information, and knowledge between digital public services EXAMPLES: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Ecolabel - EU and Member State web sites EU web site: permits to discover the types of products and services that can be awarded with the EU Ecolabel. Furthermore, the site permits to browse through the EU Ecolabel Product Catalogue and Tourist Accommodation Catalogue to find currently awarded products and services. Member State Competent Bodies provide information to businesses and consumers. Source: (http://ec.europa.eu/environment/ecolabel/index_en.htm) (https://www.ecolabel.be/fr) (https://www.gov.uk/guidance/apply-for-an-eu-ecolabel) DEFINITION: Interoperable Digital Public Services Implementation Orientation ABB is a Business Object setting decision making rules/criteria/principles followed at implementing a digital public services through organisations, persons, objects or events The following implementation orientations are identified in the literature: integration, technology, governance and legal. • The INTEGRATION ORIENTATION (Marchand et al., 2000) is characterized by a focus on data resources and on information management capabilities to manage information resources over their life cycle (i.e. scanning, collecting, organising, processing, maintaining, etc.) to understand societal needs, to embed data throughout the policy cycle, and to develop a culture of data analytics (OECD, 2018). The integration orientation will be based on semantic interoperability aiming for the design of a shared knowledge base of usable data, information and knowledge resources that enables: i) structural interoperability by using and/or sharing of data, organisational information and organisational knowledge (i.e. data set catalogue, base registries, catalogue of ontologies); ii) behavioural interoperability by exchanging capabilities of data, organisational information and organisational knowledge with the environment (i.e. representation, data mappings); and iii) governance interoperability by semantic interoperability agreements (i.e. ontologies). • The TECHNOLOGY ORIENTATION (Marchand et al., 2000) is characterized by a focus on ICT resources like solutions and infrastructure and on ICT management capabilities to manage the provision of services (i.e. business operations, decision making, internal support, etc.) to users and the consumption of services by ministries and agencies (OECD, 2018). The technology orientation will be based on technical interoperability aiming for the design of a shared platform of ICT resources (i.e. the platform) that enables: i) structural interoperability by reusing and/or sharing of software components (i.e. service registry service, networks, reusable building blocks, common [back office] services); ii) behavioural interoperability with ICT exchanging capabilities of data, information or knowledge with internal/external peers (i.e. intermediation services, interfaces); an iii) governance interoperability with technical interoperability agreements (i.e. protocols, choreography rules). • The GOVERNANCE ORIENTATION (Marchand et al., 2000) is characterized by a focus on the governance resources (Grant et al., 2007) and on governance management capabilities/archetypes to manage the effective use of information (i.e. sharing, security, privacy, etc.) for the effective use of information (i.e. sharing, security, privacy, etc.) to achieve a more agile, effective, and digitally inclusive public engagement, to increase trust in government, and to enhance government transparency (OECD, 2018; Weill & Woodham, 2002). The governance orientation will be based on organisational interoperability aiming for the design of a shared governance framework of [re]usable organisational resources that enables: i) structural interoperability by reusing and/or sharing of digital public services (i.e. public services catalogue); ii) behavioural interoperability with organisational exchanging capabilities of data, information or knowledge with internal/external peers (i.e. service delivery model); and iii) governance interoperability with organisational interoperability agreements (i.e. service level agreements, governance structures). • The LEGAL ORIENTATION (Santosuossa and Malerba, 2014) is characterized by a focus on legal and regulatory frameworks based in displayed leadership and political commitment to ensure adaptation to rapidly changing technological and diverse social environments with high-level requirements to achieve coherence and effective support to digital public services implementation (OECD, 2018). The legal orientation will be based in legal interoperability aiming for the design of a shared legal framework of [re]usable legal resources that enables: i) structural interoperability by legislation on reusing and/or sharing orientation and guidelines (i.e. legislation catalogue, interoperability reference architectures); ii) behavioural interoperability by legislation on exchanging capabilities of data, information or knowledge with internal/external peers (i.e. interoperability frameworks); and iii) governance interoperability by legislation on governance agreements (i.e. GDPR). Source: Hill & Hupe, 2002 (https://www.researchgate.net/publication/281092998_Implementing_Public_Policy_Governance_in_Theory_and_Practice). INTEROPERABILITY SALIENCY: IoP Dimension: Behavioural IoP The Interoperable Digital Public Service Implementation Orientation ABB is salient for organizational interoperability because the extent of support to the public policy goals by a digital interoperable public service might be influenced by the selected implementation orientation. EXAMPLES: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Next Generation Digital Government Architecture v1.0 by Republic of Estonia (2020) Source: (https://docs.google.com/document/d/1UJ-5wi9wavWzA2n4LhsbONJqdxjUSIgMxKJNaZZslas/edit?fbclid=IwAR2rrBNjwHFagHIvi-9Pv6uvKI0IZH_m4IdAfaq7hbjALlIjRH8nEuUVuic) Customs 2020 is an EU cooperation programme providing national customs administrations with the possibility to create and exchange information and expertise. It allows developing and operating major trans-European IT systems in partnership and establishing various human networks by bringing together national officials from across Europe. The programme has a budget of € 547.3 million and will run for 7 years from January 1 2014. Source: (https://ec.europa.eu/taxation_customs/business/customs-cooperation-programmes/customs-2020-programme_en) The intensity of the mandate given to organization enablers to implement a public policy. It can go from a strongly regulated mandate, defining the specifications, to a softly regulated mandate, defining the concept to be implemented. Based on Hill, M. and Hupe, P, Implementing Public Policy: Governance in Theory and in Practice, SAGE Publications Ltd 2002 Syn. Mission Statement The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Mandate of the Directorate of Policy Planning of the Council of Europe Directorate of Policy Planning (DPP). Overall mandate: to provide the Secretary General, the Committee of Ministers and Major Administrative Entities (MAEs) with conceptual and strategic analyses about relevant political and societal developments in Europe and beyond, based on research and on topical exchanges with internal and external networks, thereby enhancing the Organisation’s ability to anticipate major trends and challenges facing member states and to offer coherent short- and long-term responses within its statutory mandate. https://www.coe.int/en/web/portal/organisation-and-mandates-of-the-secretariat?desktop=true Mission statement of the Directorate-General for Taxation and the Customs Union The Directorate General Taxation and Customs Union's mission is to develop and manage the Customs Union, a foundation of the European Union, and to develop and implement tax policy across the EU for the benefit of citizens, businesses and the Member States. Particular attention is given to the Internal Market, by making sure it functions smoothly and efficiently. https://ec.europa.eu/taxation_customs/sites/taxation/files/resources/documents/common/about/welcome/mission_statement_en.pdf Ability to organise something well, expertise in organizing something. Based on the definitions of skill and organisational in the Oxford dictionary. https://en.oxforddictionaries.com/definition/skill Syn. Organisational Competence The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Surveillance3 - COMMISSION DECISION of 14 September 2009 setting up a European Consumer Consultative Group (2009/705/EC) One of the set of criteria for membership to the European Consumer Consultative Group membership is: be non-governmental, non-profit-making, independent of industry, commerce and business or other conflicting interests, and 1. have as their primary objectives and activities the promotion and protection of the health, safety and economic interest of consumers in the Community, 2. have been mandated to represent the interests of consumers at Community level by national consumer organisations in at least half of the Member States that are representative in accordance with national rules or practice, of consumers and are active at regional or national level, and 3. have provided to the Commission satisfactory accounts of their membership, internal rules and sources of funding http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32009D0705 Representation of the relationships between the inputs, controls, outputs, mechanisms and resources used by the activities performed in a business process. Based on TOGAF definitions. http://pubs.opengroup.org/architecture/togaf9-doc/arch/ The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Your Europe Advice - answer language Answer is given in the chosen language http://europa.eu/youreurope/advice/index_en.htm A stock or supply of money. Based on the Oxford Dictionary https://en.oxforddictionaries.com/definition/resource Syn. Funding Instrument The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): CEF Programme The Connecting Europe Facility (CEF) is a key EU funding instrument to promote growth, jobs and competitiveness through targeted infrastructure investment at European level. It supports the development of high performing, sustainable and efficiently interconnected trans-European networks in the fields of transport, energy and digital services. CEF investments fill the missing links in Europe's energy, transport and digital backbone. https://ec.europa.eu/inea/en/connecting-europe-facility A Public Service Manifestation is a behaviour EIRA© Architecture Building Block, i.e. a unit of activity performed by one or more Public Service Components. The specific methods employed to express organisational policies in action in day-to-day operations of the organization. Together, policies and procedures ensure that a point of view held by the governing body of an organization is translated into steps that result in an outcome compatible with that view. Based on BusinessDictionary.com definition of Policies and Procedures http://www.businessdictionary.com/definition/policies-and-procedures.html The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): TRACES - Listing procedures Describe how to approve or register establishments and operators on the European portal. https://ec.europa.eu/food/sites/food/files/animals/docs/ah-traces-info-mat-toolkit_en.pdf DEFINITION: EIRA view ABB is a Business Object containing a graphical notation of the EIRA ontology. The EIRA consists of several architecture views (1) , including one view for each of the EIF interoperability levels. (1) An architecture view is a representation of a system from the perspective of a related set of concerns. Source: TOGAF (https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap03.html#tag_03_17) EXAMPLES: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Legal View The Legal view models the most salient public policy development enablers and implementation instruments that shall be considered in order to support the End to End design of interoperable digital public services. Defines the process of operating a solution, how the procedures are implemented and the rules for operating it. Source: ISA2 – EIA Action The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Apache HTTP Server documentation Apache HTTP Server Version 2.4 Documentation contains pages with operational procedures, like starting the server, controlling the access, reverse proxy setup, content caching, etc. http://httpd.apache.org/docs/2.4/ DEFINITION: EIRA Architecture Building Block ABB is a Business Object acting as a requirement of an intermediate level of granularity, in alignment with at least one EIF principle, formulated as an agreed normative statement in functional terms on a legal, organisational, semantic, or technical attribute of a To-Be European Public Service. An EIRA ABB might encapsulate several interoperability aspects Source: Europa (https://ec.europa.eu/digital-building-blocks/wikis/display/CEFDIGITAL/What+is+a+Building+Block) EXAMPLES: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): A Legal Act is an EIRA Architecture Building Block from a Legal view perspective. A Specification is a document that states requirements. A specification can be related to activities (e.g. procedure document, process specification and test specification), or products (e.g. product specification, performance specification and drawing). [ISO 9000:2005] Source : https://www.iso.org/obp/ui/#iso:std:iso:9000:ed-3:v1:en:term:3.7.3 Digital Encoding of Characters. To be of any use in computers, in computer communications and in particular on the World Wide Web, characters must be encoded. In fact, much of the information processed by computers over the last few decades has been encoded text, exceptions being images, audio, video and numeric data. To achieve text encoding, a large variety of character encodings have been devised. Character encodings can loosely be explained as mappings between the character sequences that users manipulate and the sequences of bits that computers manipulate. Source: W3C https://www.w3.org/TR/2003/WD-charmod-20030822/ The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Unicode Transformation Format (UTF-8) ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems. The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8. UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. UTF-8 has a one-octet encoding unit. It uses all bits of an octet, but has the quality of preserving the full US-ASCII [US-ASCII] range: US-ASCII characters are encoded in one octet having the normal US-ASCII value, and any octet with such a value can only stand for a US-ASCII character, and nothing else. UTF-8 encodes UCS characters as a varying number of octets, where the number of octets, and the value of each, depend on the integer value assigned to the character in ISO/IEC 10646 (the character number, a.k.a. code position, code point or Unicode scalar value). https://tools.ietf.org/html/rfc3629 Defines the values of an identifier. Source: CEN BII http://spec.cenbii.eu/ The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): UUID A UUID is an identifier that is unique across both space and time, with respect to the space of all UUIDs. Since a UUID is a fixed size and contains a time field, it is possible for values to rollover. A UUID can be used for multiple purposes, from tagging objects with an extremely short lifetime, to reliably identifying very persistent objects across a network. The internal representation of a UUID is a specific sequence of bits in memory, as described in Section 4. To accurately represent a UUID as a URN, it is necessary to convert the bit sequence to a string representation. Each field is treated as an integer and has its value printed as a zero-filled hexadecimal digit string with the most significant digit first. The hexadecimal values "a" through "f" are output as lower case characters and are case insensitive on input. https://tools.ietf.org/html/rfc4122 DEFINITION: Architecture Building Block ABB is a Business Object constituting architecture model that describes a single aspect of the overall model. An Architecture Building Block describes generic characteristics and functionalities. Architecture Building Blocks are used to describe reference architectures, solution architecture templates or solution architectures of a specific solutions. Source: TOGAF (https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap03.html#tag_03_8) EXAMPLES: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): "Support" can be considered an architectural building block, when it is used in the context of the designing of a software that should include online or offline support to users. Source:(https://www.brainkart.com/article/Functional-Requirements---Software-Architectures_11271/#:~:text=The%20following%20are%20examples%20of%20explicit%20architectural%20requirements%3A,Functionality%208%20Usability%209%20Reliability%20More%20items...%20) A set of strings and an associated set of rules that describe a mapping between that set of strings and a set of resources. The mapping rules may define how the string is structured or they may simply enumerate all the strings and the corresponding resources. Source: W3C http://www.w3.org/2000/01/rdf-schema#Datatype Syn. Encoding format The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Guidelines for Dublin Core Application Profiles : date and language date: Because we want to perform automated operations like sorting on the date, we can select the Dublin Core property dcterms:date. This property can take a string value. We can indicate that the value string is formatted in accordance with the W3C Date and Time Formats specification by using syntax encoding scheme dcterms:W3CDTF. language: The language needs to be selected from a controlled list. We achieve this by requiring the use of three-letter codes listed in the international standard ISO 639-3 for the representation of names of languages (such as ""eng"" for ""English"") together with the syntax encoding scheme dcterms:ISO639-3 as a datatype. For this, we can use the DCMI property dcterms:language, which can accommodate either an identifier for the language term or a string. http://dublincore.org/documents/profile-guidelines/ https://www.w3.org/TR/NOTE-datetime A Schema-level Mapping is a mapping between related classes and properties. Source: ISO/DIS 25964-2 https://www.iso.org/standard/53658.html The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Open Contracting Data Standard schema-level mapping - Template and guidance This guide details an example of using the OCDS 1.1 Field Level Mapping Template to map the fields from a single table in a fictional e-GP system to OCDS. Step 1: Source System Details OCDS data may originate in multiple source systems, therefore it is important to record the details of the source system we are mapping from. Step 2: Source Field Details Using the (Source) Fields sheet, populate the following information for each field in the source table: the system the field is from (as recorded in step 1); the table in which the field is located; the field title. Where additional context is required you may also record a narrative description of the source field in the description field and it might also be useful to add an example of the value that the field takes alongside further technical information on the type and multiplicity of the field. Step 3: Mapping The mapping template has a sheet for each stage of the contracting process, from (OCDS) 2. Planning through to (OCDS) 6. Implementation, with details of the relevant fields from the OCDS schema, in addition to the (OCDS) 1. General (all stages) sheet which contains fields relevant to all stages of the contracting process. Review each of the (OCDS) sheets in the mapping template to identify fields in the OCDS schema to which a field in the source system can be mapped. Step 4: Review Repeat steps 1-3 for all tables and all source systems to complete the mapping. Gaps in currently held data: if you identify data OCDS requests, but that you do not hold, engage with data users to consider whether this additional data could and should be provided. Gaps in OCDS: you might have data which is not covered by OCDS. In these cases, talk with the OCDS helpdesk to see whether this should be included in an extension to the standard. Additional fields can be documented at the bottom of each mapping sheet in the template. https://www.open-contracting.org/resources/ocds-field-level-mapping-template/ https://docs.google.com/document/d/1YwDLVIhiVgKCWVJDeL2lDSKNUX1qfO1Rccxxk1n2bcU/edit#heading=h.i2ififc8i9k4 DEFINITION: Interoperability Specification ABB is a Business Object being embodied as a document of the highest possible level of granularity on an EIRA SBB, formulated as an agreed normative statement in design terms on a legal, organisational, semantic, or technical attribute of an European Public Service. It can refer to existing standards or specifications Source: ISA2 – EIA Action (https://ec.europa.eu/isa2/eif_en.) INTEROPERABILITY SALIENCY: IoP dimensions: Structural IoP, Behavioral IoP, Governance IoP EXAMPLES: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): EW-Shopp’s: With vocabulary we refer to any specification of the terminology to be used to represent information in a domain of interest. Most of vocabularies are defined within specific formal languages used by computer programs, such as XML or RDF. Source:(https://ec.europa.eu/research/participants/documents/downloadPublic?documentIds=080166e5b4c5d61e&appId=PPGMS) DESCRIPTION: A document that prescribes technical requirements to be fulfilled by a product, process or service. - Note 1 to entry: A technical specification should indicate, whenever appropriate, the procedure(s) by means of which it may be determined whether the requirements given are fulfilled. - Note 2 to entry: A technical specification may be a standard, a part of a standard or independent of a standard. Source: https://www.iso.org/obp/ui/#iso:std:iso-iec:20944:-1:ed-1:v1:en:term:3.1.3.8] INTEROPERABILITY SALIENCY: IoP Dimension: Structural IoP, Behavioral IoP, Governance IoP The Technical Specification ABB is salient for technical interoperability because it assesses the characteristics required of a product to support technical solutions. EXAMPLES: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): AS4 Profile specification The eDelivery AS4 Profile is a modular profile of the ebMS3 and AS4 OASIS specifications. Its core is a mandatory Common Profile that selects, extends and profiles the AS4 ebHandler Conformance Profile and AS4 Additional Features and provides a common Usage Profile. This Common Profile can be implemented using open source or closed source AS4 software implementations. It is aligned with, and corresponds to a subset of, the AS4 profile for TSOs (Transmission System Operators) developed by ENTSOG (the European Network of Transmission System Operators for Gas). In addition to the Common Profile, this specification provides a number of optional Profile Enhancement modules that specify functionality enhancements covering AS4 message exchange in four corner topologies, the use of AS4 in conjunction with the UN/CEFACT Standard Business Document Header (SBDH) specification, and Dynamic Receiver and Dynamic Sender behavior. https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/eDelivery+AS4+-+1.13 DEFINITION: Interoperability Governance ABB is a Business Object assuring the functioning of an Interoperability Framework. These rules include structures, roles, responsibilities, policies, standards, specifications, practices, decision making and operational procedures. Source: EIF (http://eur-lex.europa.eu/resource.html?uri=cellar:2c2f2554-0faf-11e7-8a35-01aa75ed71a1.0017.02/DOC_3&format=PDF) Syn. Interoperability management method or system INTEROPERABILITY SALIENCY: IoP Dimension: Governance IoP The Interoperability Governance ABB  is an interoperability enabler because it helps achieve organisational interoperability as it is " the key to a holistic approach on interoperability, as it brings together all the instruments needed to apply it" (EIF). As stated in EIF Recommendation 20: "Ensure holistic governance of interoperability activities across administrative levels and sectors." EXAMPLES: The following implementations are examples on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): INSPIRE Directive 2007/2/EC of 14 March 2007, Article 18 Member States shall ensure that appropriate structures and mechanisms are designated for coordinating, across the different levels of government, the contributions of all those with an interest in their infrastructures for spatial information. These structures shall coordinate the contributions of, inter alia, users, producers, added-value service providers and coordinating bodies, concerning the identification of relevant data sets, user needs, the provision of information on existing practices and the provision of feedback on the implementation of this Directive. Source: (http://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32007L0002&from=EN) Governance defined in the new European Interoperability Framework (EIF) § 3.1 of the new EIF Annex II: Interoperability governance refers to decisions on interoperability frameworks, institutional arrangements, organisational structures, roles and responsibilities, policies, agreements and other aspects of ensuring and monitoring interoperability at national and EU levels. The European interoperability framework, the Interoperability Action Plan (Annex 1 to the Communication) and the European interoperability architecture (EIRA) are important parts of interoperability governance at the EU level. Source:(http://eur-lex.europa.eu/resource.html?uri=cellar:2c2f2554-0faf-11e7-8a35-01aa75ed71a1.0017.02/DOC_3&format=PDF) DEFINITION: Reference Data Policy ABB is a Business Object being applied to data used to organise or categorise other data, or for relating data to information both within and beyond the boundaries of the enterprise. Usually it mandates the use of codes and descriptions, or definitions. Source: DAMA DM_BOK (http://www.dama.org) Reference data consists typically of a small, discrete set of values that are not updated as part of business transactions but are usually used to impose consistent classification. Reference data normally has a low update frequency. Reference data is relevant across more than one business systems belonging to different organisations and sectors [Source: J. Jordan & C. Ellen (2009). Business need, data and business intelligence]. INTEROPERABILITY SALIENCY: IoP Dimension: Governance IoP The Reference Data Policy ABB is salient for semantic interoperability because Reference Data can be shared and reused (e.g. in the form of taxonomies or controlled vocabularies) between organisation to agree on some basic information. Management of reference data is a priority as suggested by EIF's recommendation 31: "Put in place an information management strategy at the highest possible level to avoid fragmentation and duplication. Management of metadata, master data and reference data should be prioritised." EXAMPLES: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): FIRDS Reference Data System The intended audience of this document is National Competent Authorities, Trading Venues Systematic Internalisers and Data Reporting Service Provider (including Approved Publication Arrangement and Consolidated Tape Providers), who are going to implement system interfaces for the uploading of data to the Financial Instruments Reference Data System. This document aims to specify the exchange of Reference Data Information (RDI) between NCAS, Trading Venues, Systematic Internalisers and the Financial Instruments Reference System. Source: (https://www.esma.europa.eu/sites/default/files/library/esma65-11-1193_firds_reference_data_reporting_instructions_v2.0.pdf) Principles, rules, and guidelines formulated or adopted by an organization to reach its long-term goals and typically published in a booklet or other form that is widely accessible. Policies and procedures are designed to influence and determine all major decisions and actions, and all activities take place within the boundaries set by them. Based on BusinessDictionary.com definition of Policies and Procedures http://www.businessdictionary.com/definition/policies-and-procedures.html The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Inspire - re-use of public sector information Directive 2003/98/EC of the European Parliament and of the Council of 17 November 2003 on the re-use of public sector information. This Directive establishes a minimum set of rules governing the re-use and the practical means of facilitating re-use of existing documents held by public sector bodies of the Member States. http://eur-lex.europa.eu/legal-content/en/TXT/?uri=CELEX:32003L0098 DEFINITION: Solution Specification ABB is a Business Object being embodied as a document of the highest possible level of granularity on an Solution Building Block, formulated as an agreed normative statement in design of an European Public Service. Source: ISO (https://www.iso.org/standard/40359.html) EXAMPLES: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Semantic interoperability requirements concern also the specification of data formats, vocabularies and systems of identifiers that need to be supported to support interoperability within the EWShopp project. In addition, exploitation of the technology developed within the project outside the project consortium makes convenient to reuse whenever possible data formats, vocabularies and systems of identifiers that are the results of standardization efforts across Europe. Source: (https://ec.europa.eu/research/participants/documents/downloadPublic?documentIds=080166e5b4c5d61e&appId=PPGMS) The process responsible for maintaining information about configuration Items required to deliver an IT Service, including their relationships. Based on ITIL v3 https://www.axelos.com/Corporate/media/Files/Glossaries/AXELOS-Common-Glossary.pdf The following implementation are examples on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Syn. [Distributed] Version Control, Source Code Management Quattor Quattor is a system administration toolkit providing a powerful, portable, and modular set of tools for the automated installation, configuration, and management of clusters, farms, grids and clouds. Quattor is developed as a community effort and provided as open-source software under the Apache 2.0 license and EU DataGrid Software License. Quattor was originally developed in the framework of European Data Grid project. Since its first release in 2003, Quattor has been maintained and extended by a volunteer community of users and developers, primarily from the community of grid system administrators. Three features make it particularly attractive for managing grid resources: Federated Management, Shared Configuration and Management Efficiency, Coherent Site Model. http://www.quattor.org/ Salt Salt (also called SaltStack Platform) is a Python-based open-source configuration management software and remote execution engine supporting the "Infrastructure as code" approach to deployment and cloud management. SaltStack takes a new approach to infrastructure management by developing software that is easy enough to get running in seconds, scalable enough to manage tens of thousands of servers, and fast enough to control and communicate with them in milliseconds. SaltStack delivers a dynamic infrastructure communication bus used for orchestration, remote execution, configuration management and much more. The Salt Open project was launched in 2011 and is one of the fastest-growing, most-active infrastructure orchestration and configuration management open source project in the world. The SaltStack community is committed to keeping the Salt Open project focused, healthy and open. https://saltstack.com/community/ DESCRIPTION: A specification contained in a document which lays down the characteristics required of a product such as levels of quality, performance, safety or dimensions, including the requirements applicable to the product as regards the name under which the product is sold, terminology, symbols, testing and test methods, packaging, marking or labelling and conformity assessment procedures. Source: Directive 98/34/EC laying down a procedure for the provision of information in the field of technical standards and regulations and of rules on Information Society services; http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CONSLEG:1998L0034:20070101:EN:PDF INTEROPERABILITY SALIENCY: IoP dimensions: Structural IoP, Behavioral IoP, Governance IoP The Technical Interoperability Specification ABB is salient for technical interoperability because it assesses the characteristics required of a product to support interoperability solutions. EXAMPLES: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): HTTPS specification HTTP [RFC2616] was originally used in the clear on the Internet. However, increased use of HTTP for sensitive applications has required security measures. SSL, and its successor TLS [RFC2246] were designed to provide channel-oriented security. https://tools.ietf.org/html/rfc2818 A Data-level Mapping is a mapping between specific data elements (or data values). Source: ISO/DIS 25964-2 https://www.iso.org/standard/53658.html The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): eConfidentiality - Mapping with documents and metadata in Case Management System Mapping between documents and metadata in eConfidentiality system with documents and metadata in Case Management System. N.B. Context: All documents concerning an anti-trust case are stored by case number in the case management application called "CMAfx". Documents are stored in different formats: pdf format (if available in paper form only and subsequently digitised) or word, excel, tif, rtf, html, txt version (if received as such or produced by DG Competition). CMAfx contains also procedural steps and case information, such as the composition of the case team, relevant legal basis, type of case, priority, name of undertaking concerned etc. Access to CMAfx is restricted to DG Competition personnel and national experts on secondment using DG Competition IT infrastructure. The undertakings answering the queries are obliged to indicate the confidentiality status of their responses, i.e., whether their answer must be treated as confidential, and in that case the system does not allow submission of their responses until a non-confidential answer has been provided for each confidential one. The non-confidential versions of the Commission's decisions adopted pursuant to articles 7-10, 23 and 24 of Regulation 1/2003 are published on DG Competition website, after the confidentiality claims (with regard to business secrets and other confidential information) were cleared with the respective parties. http://ec.europa.eu/dpo-register/details.htm?id=38367 An organisation, person, object or event that makes it possible to formulate or implement the a public policy. Based on Hill, M. and Hupe, P, Implementing Public Policy: Governance in Theory and in Practice, SAGE Publications Ltd 2002 An [Operational Enabler] is influenced by a [Public Policy Implementation Approach] and a [Public Policy Implementation Mandate] which determine the role of the organisation, person, object or event. This role is determined by the following quadrant: | Public Policy Implementation Approach | |___________________________________________| | Top / Centralised | Down / Delegated | ______________________________________________________|______________________|____________________| | | | | Public | Strongly / Low Level Regulated | A | B | Policy | ___________________________________| _____________________| ____________________| Implementation | | | | Mandate | Softly / High Level Regulated | C | D | __________________| ___________________________________|______________________|____________________| Option A: Public Policy Implementation Mandate: Strongly / Low Level Regulated, Public Policy Implementation Approach: Top / Centralised SETTING THE PUBLIC POLICY KEY IMPLEMENTATION IOP INSTRUMENTS (i.e. focus on data architecture like a base registry solution) Option B: Public Policy Implementation Mandate: Strongly / Low Level Regulated, Public Policy Implementation Approach: Down / Delegated SETTING PUBLIC POLICY IMPLEMENTATION STANDARDS AND RULES (i.e. focus on technology architecture like eID tech specifications) Option C: Public Policy Implementation Mandate: Softly / High Level Regulated, Public Policy Implementation Approach: Top / Centralised SETTING PUBLIC POLICY IMPLEMENTATION OBJECTIVES (i.e. focus on business architecture like a national interoperability strategy) Option D: Public Policy Implementation Mandate: Softly / High Level Regulated, Public Policy Implementation Approach: Down / Delegated SETTING PUBLIC POLICY IMPLEMENTATION FRAMEWORKS AND COLLABORATION PROTOCOLS CROSS THE DIFFERENT DELEGATION LEVELS (i.e. focus on application architecture like a national reference architecture) The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): The Customs 2020 Programme Customs 2020 is an EU cooperation programme providing national customs administrations with the possibility to create and exchange information and expertise. It allows developing and operating major trans-European IT systems in partnership and establishing various human networks by bringing together national officials from across Europe. The programme has a budget of € 547.3 million and will run for 7 years from January 1 2014. https://ec.europa.eu/taxation_customs/business/customs-cooperation-programmes/customs-2020-programme_en DESCRIPTION: This aspect of interoperability is concerned with how organisations, such as public administrations in different Member States, cooperate to achieve their mutually agreed goals. In practice, organisational interoperability implies integrating business processes and related data exchange. Organisational interoperability also aims to meet the requirements of the user community by making services available, easily identifiable, accessible and user-focused. Organisation interoperability specifications support organisational interoperability by addressing the core organizational interoperability background for solutions. Source: How does the EIRA© support interoperability? https://joinup.ec.europa.eu/sites/default/files/how_does_eira_support_interoperability_v1_0_0.pdf EXAMPLES: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Memorandum of Understanding on Economic and Financial Statistics between the DG Statistics of the European Central Bank and Eurostat The purpose of this Memorandum of Understanding is to set out the respective areas of responsibility in economic and financial statistics at the Community level of the ECB (Directorate General Statistics) and the Commission (Eurostat); to provide a framework for the exchange and reproduction of data; to note the forms which co-operation between the Directorate General Statistics (DG Statistics) and Eurostat will take; and to set down a procedure for resolving disagreements. https://www.ecb.europa.eu/ecb/legal/pdf/en_mou_with_eurostat1.pdf DESCRIPTION: An Legal Interoperability Specification is a document of the highest possible level of granularity on an EIRA SBB, formulated as an agreed normative statement in design terms on a legal attribute of an European Public Service. It can refer to existing standards or specifications.” Source: How does the EIRA© support interoperability? https://joinup.ec.europa.eu/sites/default/files/how_does_eira_support_interoperability_v1_0_0.pdf INTEROPERABILITY SALIENCY: IoP Dimension: Structural IoP, Behavioral IoP, Governance IoP The Legal Interoperability Specification ABB is relevant for interoperability a key interoperability enabler because it helps achieve legal interoperability by addressing the core legal interoperability background for solutions. EXAMPLES: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): e-procurement SAT - Directive 2014/24/EU on public procurement DIRECTIVE 2014/24/EU OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 26 February 2014 on public procurement and repealing Directive 2004/18/EC (Text with EEA relevance). The directive sets out rules on the use of public contracts for the provision of works, supplies or services by companies or individuals and the exemptions which can be applied. The legislation specifies that when national authorities use public procurement to invite tenders to provide works, supplies or services, they must treat all applicants equally and not discriminate between them. They must also be transparent in their dealings. This Directive is considered as a Legal Interoperability Specification, as it shall be transposed in a National or Regional Binding Instrument when designing the solution using the e-procurement Solution Architecture Template. https://joinup.ec.europa.eu/asset/eia/description A Public Service Component is a structural EIRA© Architecture Building Block, i.e. an entity which can perform behaviour (active structure) or on which behaviour is performed (passive structure). Public Policy Formulation Instrument: Technique or means for the development of pertinent and acceptable proposed courses of action for dealing with public problems. Public Policy Implementation Instrument: Technique or means for the carrying out of a policy decision. This ABB is a key interoperability enabler (*) for assessing the compatibility of legal/juridical certainty in exchanged information. (*)DECISION (EU) 2015/2240 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 25 November 2015 establishing a programme on interoperability solutions and common frameworks for European public administrations, businesses and citizens (ISA2 programme) as a means for modernising the public sector. Based on NCPI and OECD definitions. https://web.stanford.edu/group/ncpi/unspecified/assessment_states/framework.html https://www.oecd.org/edu/ceri/The%20Nature%20of%20Policy%20Change%20and%20Implementation.pdf The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Article 168 TFEU, ex Article 152 TEC 1. A high level of human health protection shall be ensured in the definition and implementation of all Union policies and activities. Union action, which shall complement national policies, shall be directed towards improving public health, preventing physical and mental illness and diseases, and obviating sources of danger to physical and mental health. Such action shall cover the fight against the major health scourges, by promoting research into their causes, their transmission and their prevention, as well as health information and education, and monitoring, early warning of and combating serious cross-border threats to health. The Union shall complement the Member States' action in reducing drugs-related health damage, including information and prevention. 2. The Union shall encourage cooperation between the Member States in the areas referred to in this Article and, if necessary, lend support to their action. It shall in particular encourage cooperation between the Member States to improve the complementarity of their health services in cross-border areas. Member States shall, in liaison with the Commission, coordinate among themselves their policies and programmes in the areas referred to in paragraph 1. The Commission may, in close contact with the Member States, take any useful initiative to promote such coordination, in particular initiatives aiming at the establishment of guidelines and indicators, the organisation of exchange of best practice, and the preparation of the necessary elements for periodic monitoring and evaluation. The European Parliament shall be kept fully informed. 3. The Union and the Member States shall foster cooperation with third countries and the competent international organisations in the sphere of public health. 4. By way of derogation from Article 2(5) and Article 6(a) and in accordance with Article 4(2)(k) the European Parliament and the Council, acting in accordance with the ordinary legislative procedure and after consulting the Economic and Social Committee and the Committee of the Regions, shall contribute to the achievement of the objectives referred to in this Article through adopting in order to meet common safety concerns: (a) measures setting high standards of quality and safety of organs and substances of human origin, blood and blood derivatives; these measures shall not prevent any Member State from maintaining or introducing more stringent protective measures; (b) measures in the veterinary and phytosanitary fields which have as their direct objective the protection of public health; (c) measures setting high standards of quality and safety for medicinal products and devices for medical use. 5. The European Parliament and the Council, acting in accordance with the ordinary legislative procedure and after consulting the Economic and Social Committee and the Committee of the Regions, may also adopt incentive measures designed to protect and improve human health and in particular to combat the major cross-border health scourges, measures concerning monitoring, early warning of and combating serious cross-border threats to health, and measures which have as their direct objective the protection of public health regarding tobacco and the abuse of alcohol, excluding any harmonisation of the laws and regulations of the Member States. 6. The Council, on a proposal from the Commission, may also adopt recommendations for the purposes set out in this Article. 7. Union action shall respect the responsibilities of the Member States for the definition of their health policy and for the organisation and delivery of health services and medical care. The responsibilities of the Member States shall include the management of health services and medical care and the allocation of the resources assigned to them. The measures referred to in paragraph 4(a) shall not affect national provisions on the donation or medical use of organs and blood. http://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:12008E168&from=EN General rules, principles, or pieces of advice to put a public policy into effect. Based on the Oxford Dictionary https://en.oxforddictionaries.com/definition/guideline Syn. Recommendations and Standards The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): European Code of Good Conduct for microcredit provision This European Code of Good Conduct for microcredit provision, published by the European Commission in October 2011, provides recommendations and standards that should foster best practice in the microcredit sector. It is intended to provide guidance for microcredit providers from the point of view of consumers, investors, funders and regulators. http://ec.europa.eu/regional_policy/en/information/publications/brochures/2011/european-code-of-good-conduct-for-microcredit-provision DEFINITION: Data Syntax ABB is a Business Object defining the way in which data is put together with appropriate identifiers, delimiters, separator character(s), and other non-data characters to form messages. Source: ISO (https://www.iso.org/obp/ui/#iso:std:iso:14817:-1:ed-1:v1:en:term:4.59) INTEROPERABILITY SALIENCY: IoP Dimension: Structural IoP, Behavioral IoP, Governance IoP The Data Syntax ABB is salient for semantic interoperability because it provides the rules establishing how data have to to be written. EXAMPLES: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): XML syntax XML syntax refers to the rules that determine how an XML application can be written. The XML syntax is very straight forward, and this makes XML very easy to learn. Below are the main points to remember when creating XML documents. Source: (https://www.quackit.com/xml/tutorial/xml_syntax.cfm) DEFINITION: Data Entity ABB is a Business Object being used as a classification of objects found in the real world described by the Noun part of speech – persons, places, things, concepts, and events – of interest to the enterprise. Source: DAMA DM_BOK (http://www.dama.org) Syn. Coherent set of information INTEROPERABILITY SALIENCY: IoP Dimension: Structural IoP, Behavioral IoP, Governance IoP The Data Entity ABB is salient for semantic interoperability because it represents a basic component of a Data Model ABB. EXAMPLES: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): EURES - Job vacancy Most of the jobs on the EURES Job Mobility Portal come from the job vacancies databases managed by the Public Employment Services of the countries participating in EURES. Using a technology called Web Services, the EURES search engine instantly, in real time, interrogates each national database for jobs. These jobs can be of two types: “EURES jobs", displayed with a blue flag, which are jobs where an employer has expressed an interest in recruiting from another country, or any other jobs advertised in the national jobs databases. There is, in addition, a central database where EURES advisers can manually post jobs that will all be flagged as "EURES jobs". This is for the time being the only way for those few countries that are not yet fully connected to Web Services to advertise jobs on the EURES portal. This solution can, however, also be used for other specific purposes, such as when an employer wishes to publish a vacancy in several languages etc., which may not always be possible in a national database. Source: (https://ec.europa.eu/eures/public/en/advertise-a-job?lang=en&app=1.8.1p6-build-0&pageCode=advertise_job) DEFINITION: Key Interoperability Enabler ABB is a Business Object enabling the efficient and effective delivery of public services across administrations. Source: European Commission, ISA Programme (https://ec.europa.eu/isa2/sites/default/files/eif_brochure_final.pdf) EXAMPLES: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): The European Digital Identity will be available to EU citizens, residents, and businesses who want to identify themselves or provide confirmation of certain personal information. It can be used for both online and offline public and private services across the EU. The Digital Identity is a key interoperability enabler because it enables the efficient and effective delivery of Identification. Source: (https://ec.europa.eu/info/strategy/priorities-2019-2024/europe-fit-digital-age/european-digital-identity_en#:~:text=Digital%20Identity%20for%20all%20Europeans%20The%20European%20Digital,offline%20public%20and%20private%20services%20across%20the%20EU.) DEFINITION: Conformance Test Report ABB is a Business Object testing activities and subsequently consolidated in a report to inform stakeholders. Source: ISTQB (http://glossary.istqb.org/search/test) Syn. Test results INTEROPERABILITY SALIENCY: IoP Dimension: Structural IoP The Conformance Test Report ABB  is salient for technical interoperability because it provides reports of data testing to inform stakeholders. EXAMPLES: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Jenkins jUnit plug-in The JUnit plugin provides a publisher that consumes XML test reports generated during the builds and provides some graphical visualization of the historical test results (see JUnit graph for a sample) as well as a web UI for viewing test reports, tracking failures, and so on. Jenkins understands the JUnit test report XML format (which is also used by TestNG). When this option is configured, Jenkins can provide useful information about test results, such as trends. Source: (https://wiki.jenkins.io/display/JENKINS/JUnit+Plugin) DEFINITION: Solution ABB is a Business Object consisting of one or more Solution Building Blocks to meet a certain stakeholder need. Within the context of the EIRA©, a solution is usually an Interoperable European Solution developed by public administrations that facilitate the delivery of electronic Public Services and cross-border exchange of information between public administrations or Citizens in support to the implementation and advancement of EU, national or local public policies. Source: TOGAF (https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap03.html#tag_03_69) EXAMPLES: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Eur-Lex (stylized EUR-Lex) is an official website solution of European Union law and other public documents of the European Union (EU), published in 24 official languages of the EU. The Official Journal (OJ) of the European Union is also published on Eur-Lex. Users can access Eur-Lex free of charge and also register for a free account, which offers extra features. Source: (https://eur-lex.europa.eu/homepage.html?locale=en) DEFINITION: Interoperability Strategy ABB is a Business Object enabling an overarching strategic plan in the area of cross-border interoperability. Source: ISA2 https://ec.europa.eu/isa2/actions/continuously-updating-european-interoperability-strategy_en INTEROPERABILITY SALIENCY: IoP Dimension: Governance IoP The Interoperability Strategy ABB  is an interoperability enabler because it helps achieve organisational interoperability by setting up the vision and principles for the development of the interoperability capabilities. The European Interoperability Framework implements the European Interoperability Strategy. EXAMPLES: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): European Interoperability Strategy (EIS) COMMUNICATION FROM THE COMMISSION TO THE EUROPEAN PARLIAMENT, THE COUNCIL, THE EUROPEAN ECONOMIC AND SOCIAL COMMITTEE AND THE COMMITTEE OF THE REGIONS - Towards interoperability for European public services This Communication introduces the European Interoperability Strategy (EIS) and the European Interoperability Framework (EIF) for European public services, two key elements in the Digital Agenda. Together, they promote interoperability among public administrations. The European Interoperability Strategy (EIS) is developed by the European Commission’s Directorate-General for Informatics. The EIS aims to provide guidance and to prioritise the actions needed to improve interaction, exchange and cooperation among European public administrations across borders and across sectors for the delivery of European public services. Source: (http://eur-lex.europa.eu/resource.html?uri=cellar:f132547a-7d66-4626-8eb6-9f7428394de7.0017.03/DOC_2&format=PDF) The hierarchical arrangement of lines of authority, communications, rights and duties of an organization. Organizational structure determines how the roles, power and responsibilities are assigned, controlled, and coordinated, and how information flows between the different levels of management. Based on BusinessDictionary.com definition of Organizational Structure http://www.businessdictionary.com/definition/organizational-structure.html The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): EUCARIS - registry network EUCARIS is an initiative of several European countries and can be described as a cooperation between several national registration authorities. Formalised in a multilateral treaty, this cooperation is focused on the data-exchange regarding vehicle registration, driving licences, and the accompanying personal data. For this exchange, a system is used which was especially developed for this purpose: EUCARIS II. It is essential to note that EUCARIS makes no use of a central European database. Each country is responsible for its own registry of vehicle and driving licence information and its own registration procedures. Through their national registration authority other government institutions can request information on e.g. vehicles from another country. The national registration authority becomes a central hub in EUCARIS. https://joinup.ec.europa.eu/document/eucaris-european-car-and-driving-licence-information-system-eucaris-0 DEFINITION: Public Service Catalogue ABB is a Business Object indexing inventory of active digital public services, and their descriptions, that are provided by a public administration. This ABB is a key interoperability enabler (*) for sharing/PROVISIONING and reusing/CONSUMING of front-office public services. Source: ISA2 Core Vocabularies (https://joinup.ec.europa.eu/catalogue/distribution/cpsv-ap-specification-v20-pdf) (*)DECISION (EU) 2015/2240 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 25 November 2015 establishing a programme on interoperability solutions and common frameworks for European public administrations, businesses and citizens (ISA2 programme) as a means for modernising the public sector. Syn. Public Service Registry, Public Service Inventory INTEROPERABILITY SALIENCY: IoP Dimension: Structural IoP The Public Service Catalogue ABB is a key interoperability enabler because it supports to achieve organisational structural interoperability by ensuring the provision/consumption of front-office digital public services. Catalogues are also key element of the EIF "Integrated Public Service Governance" conceptual model. According to EIF Recommendation 44: "Put in place catalogues of public services, public data, and interoperability solutions and use common models for describing them." EXAMPLES: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): FEDICT service catalogue FEDICT, part of the Federal Public Service Policy and Support of Belgium, offers a public service catalogue. Here are a few examples of the offered services: Company data (company information and certificates), Digiflow (access to online certificates), E-mail Relay (relay of e-mail to and from the federal public services and institutions, as a protection to viruses and spam), eBirth (birth online notification and transfer of statistics), eDepot (for notaries), Federal Authentication Service (authentication of individuals for access to online government applications), etc. Source: (http://www.fedict.belgium.be/en/service_catalogue) A Public Policy Development Enabler is an organisation or thing that make the development and implementation of the Public Policy possible. [Oxford Dictionary] Source: http://www.oxforddictionaries.com/definition/english/enabler DEFINITION: Descriptive Metadata Policy ABB is a Business Object aiming at making data discoverable and identifiable. It may mandate elements such as title, abstract, author, and keywords. Source: Niso (http://www.niso.org/publications/press/UnderstandingMetadata.pdf) INTEROPERABILITY SALIENCY: IoP Dimension: Governance IoP The Descriptive Metadata Policy ABB is salient for semantic interoperability because metadata facilitates opening and sharing data by providing the appropriate format, description of the content, high level of quality in order to achieve interoperability as stated in the EIF recommendation n° 42: "[..] Ensure that open data is accompanied by high quality, machine-readable metadata in non-proprietary formats, including a description of their content, the way data is collected and its level of quality and the licence terms under which it is made available. The use of common vocabularies for expressing metadata is recommended." EXAMPLES: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Dublin Core Metadata Element Set, Version 1.1: Reference Description The Dublin Core Metadata Element Set is a vocabulary of fifteen properties for use in resource description. The name "Dublin" is due to its origin at a 1995 invitational workshop in Dublin, Ohio; "core" because its elements are broad and generic, usable for describing a wide range of resources. The fifteen element "Dublin Core" described in this standard is part of a larger set of metadata vocabularies and technical specifications maintained by the Dublin Core Metadata Initiative (DCMI). The full set of vocabularies, DCMI Metadata Terms [DCMI-TERMS], also includes sets of resource classes (including the DCMI Type Vocabulary [DCMI-TYPE]), vocabulary encoding schemes, and syntax encoding schemes. The terms in DCMI vocabularies are intended to be used in combination with terms from other, compatible vocabularies in the context of application profiles and on the basis of the DCMI Abstract Model [DCAM]. Source: (http://dublincore.org/documents/dces/) That which allows how organisations cooperate to achieve their mutually agreed goals. It can be capabilities, forces, or resources. Source: Based on the Black's Law Dictionary definition of enablers and the EIRA definition of organisational interoperability. https://joinup.ec.europa.eu/asset/eia/document/how-does-eira-support-interoperability http://thelawdictionary.org/enablers/ The following implementations are examples on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): RAPEX - Semantic Web Gate Public set of RAPEX notifications are available via the Semantic Web Gate in the Open Data portal http://ec.europa.eu/semantic_webgate/query/dataset=rapex e-Justice Portal - Commission's approach on the security of communication and information systems in the European Commission Commission Decision (EU, Euratom) 2017/46 of 10 January 2017 on the security of communication and information systems in the European Commission. The Commission's approach should take into account EU policy initiatives and legislation on network and information security, industry standards and good practices, to comply with all relevant legislation and to allow interoperability and compatibility. This decision applies to all communication and information systems (CISs) which are owned, procured, managed or operated by or on behalf of the Commission and all usage of those CISs by the Commission. This decision sets out the basic principles, objectives, organisation and responsibilities regarding the security of those CISs, and in particular for Commission departments owning, procuring, managing or operating CISs and including CISs provided by an internal IT service provider. http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv:OJ.L_.2017.006.01.0040.01.ENG DEFINITION: Data Policy ABB is a Business Object being applied to a trusted authentic source of information under the control of an appointed public administration or organisation appointed by government. According to the European Interoperability Framework, base registries are: “reliable sources of basic information on items such as persons, companies, vehicles, licenses, buildings, locations and roads” and “are authentic and authoritative and form, separately or in combination, the cornerstone of public services”. Source: EIF (http://eur-lex.europa.eu/resource.html?uri=cellar:2c2f2554-0faf-11e7-8a35-01aa75ed71a1.0017.02/DOC_3&format=PDF) INTEROPERABILITY SALIENCY: IoP Dimension: Governance IoP The Base Registry Data Policy ABB is salient for semantic interoperability because base registries include "authorative sources of information", that need to be properly governed and made available. EIF's includes base registries in the conceptual model for integrated public services, and describes it as "the cornerstone of European public service delivery". EIF gives several recommendations on how to manage and interact with base registries (recommendation 37, 38, 39 and 40). EXAMPLES: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): GOOD PRACTICES ON BUILDING SUCESSFUL INTERCONNECTIONS OF BASE REGISTRIES In order to provide quick and user-friendly public services to citizens and businesses, public administrations are trying to adopt customer-centric approaches and readjust their ways of working. One way to achieve efficiency and increase user-friendliness is through the ‘once-only principle’. Instead of asking the citizen for information that they have already provided, public administrations will reuse the information they already have. Much of this information is stored in authoritative databases called base registries. As the authentic sources of data for public administrations, base registries are one of the basic building blocks of public services and are the key to making the once-only principle a reality. The document contains some good practices to foster access to the data contained in these base registries. The good practices presented, are grouped according to the layered interoperability model proposed by the European Interoperability Framework (EIF). Source: (https://ec.europa.eu/isa2/sites/isa/files/publications/access-to-base-registries-good-practices-on-building-successful-interconnections-of-base-registries.pdf) DEFINITION: EIRA viewpoint ABB is a Business Object providing a perspective with specific stakeholders concern in mind. The EIRA© provides several viewpoints that conform to EIRA© views (1) A specification of the conventions for a particular kind of architecture view. Source: TOGAF (https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap03.html#tag_03_18) EXAMPLES: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Highlevel viewpoint The EIRA© Highlevel viewpoint models an introductory overview of the focal Architecture Building Blocks of each view. It aligns the EIRA© with the service delivery model described within the Interoperability Maturity Model (IMM), and the New European Interoperability Framework (EIF) conceptual model for public services. The ABBs included in the high-level viewpoint represent the points that link the EIRA©’s views enabling traceability between their different Architecture Building Blocks. They are not necessarily mandatory but should always be considered by a user of the EIRA© when executing one of its use cases. The set of rules and practices that regulate how sensitive information, individual's information and other resources are managed, protected and distributed. Based on IATE definitions of "security policy" and Black's Dictionary of Law definition of "privacy". http://iate.europa.eu/ http://thelawdictionary.org/privacy/ Syn. Security and Privacy Statement The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Policy about personal information displayed on the INSPIRE Knowledge Base All personal information displayed on the INSPIRE Knowledge Base and subsites is subject to a Specific Privacy Statement, accepted by the data subject prior to the collection of his/her personal data, and is published with his/her unambiguous consent. This e-service is operated by the Digital Economy Unit, Joint Research Centre (JRC). The objective of the INSPIRE Knowledge Base is to provide the INSPIRE community a space on the Internet where they can share information, documents, participate in discussion fora, and share best practices. Upon registration, your personal data will be collected and further processed. The Digital Economy Unit who manages the processing acts as personal data processor. As this processing collects and further processes personal data, Regulation (EC) 45/2001, of the European Parliament and of the Council of 18 December 2000 on the protection of individuals with regard to the processing of personal data by the Community institutions and bodies and on the free movement of such data, is applicable. The Privacy Statement covers the following: • What is the personal information collected, what is the legal basis, for what purpose and through which technical means? • Who has access to the information and to whom is it disclosed? • How is the information protected and safeguarded? • How can personal information be verified, modified or deleted information? • How long is the data kept? • Contact Information • Recourse http://inspire.ec.europa.eu/privacy-policy/59294 A Public Policy Implementation is the process of putting a public policy into effect. [Oxford Dictionary] DESCRIPTION: Data mapping is an equivalence relationship between two data items with ontological value. Data mapping is used for a wide variety of tasks, including: - Data mediation between a data source and a destination; - Data transformation - Identification of data relationships as part of data lineage analysis; - Discovery of hidden sensitive data such as the last four digits of a social security number hidden in another user id as part of a data masking or de-identification project; - Consolidation of multiple databases into a single database and identifying redundant columns of data for consolidation or elimination. INTEROPERABILITY SALIENCY IoP Dimension: Behavioral IoP The Data Mapping ABB is a key interoperability enabler because it supports to achieve legal behavioral interoperability by enabling the exchange of data, information, and knowledge between digital public services. EXAMPLE The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Microsoft Dynamics CRM Mapping Schema: Microsoft Dynamics CRM contains several data sets which comprise of different objects, such as Leads, Opportunities, and Competitors. Each of these data sets has several fields like Name, Account Owner, City, Country, Job Title, and more. The application has a defined schema along with attributes, enumerations, and mapping rules. Therefore, if a new record is to be added to the schema of a data object, a data map needs to be created from the data source to the Microsoft Dynamics CRM account. A Public Policy Evaluation is an assessment of how the public policy met its objectives (according to defined criteria). Source: Based on the concepts laid out in http://www.europarl.europa.eu/RegData/etudes/etudes/join/2013/507457/IPOL-IMCO_ET(2013)507457_EN.pdf A Formulation of Public Policy Scenarios is a stage where a number of public policy options for addressing the problem and achieving the public policy objectives are developed. Source: Based on the concepts laid out in http://www.europarl.europa.eu/RegData/etudes/etudes/join/2013/507457/IPOL-IMCO_ET(2013)507457_EN.pdf A Definition of Public Policy Objectives is a stage where public policy objectives are defined. Source: Based on the concepts laid out in http://www.europarl.europa.eu/RegData/etudes/etudes/join/2013/507457/IPOL-IMCO_ET(2013)507457_EN.pdf An Impact assessment is a key tool to ensure that the public policy process is carried out on the basis of transparent, comprehensive and balanced evidence, an Impact assessment is an aid to political decision-making. Source: Based on the concepts laid out in http://ec.europa.eu/smart-regulation/impact/commission_guidelines/docs/iag_2009_en.pdf DEFINITION: Public Service Consumer ABB is a Business Role consuming public services. Source: EIF 2.0 (http://ec.europa.eu/isa/documents/isa_annex_ii_eif_en.pdf) INTEROPERABILITY SALIENCY: IoP Dimension: Governance IoP The Public Service Consumer ABB is salient for organisational interoperability because it is one of the main actors involved in the interoperability of the public service as stated in the EIF: "Service orientation, upon which the conceptual model for public services is conceived, means that the relationship between service providers and service consumers must be clearly defined". EIF Recommendation n.29 also suggests: "Clarify and formalise your organisational relationships for establishing and operating European public services." EXAMPLES: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Cosmetic Product Notification Portal CPNP - Poison centre, Responsible person, Market surveillance authority, Distributor, Health advisor, Administrations The CPNP is making this information available electronically to: • Competent Authorities (for the purposes of market surveillance, market analysis, evaluation and consumer information) • Poison Centres or similar bodies established by EU countries (for the purposes of medical treatment). Source: (https://ec.europa.eu/growth/sectors/cosmetics/cpnp_fr) DEFINITION: Public Service Consumer Agent ABB is a Business Role consuming a public service on behalf of a principal. Source: Joinup (https://joinup.ec.europa.eu/rdf_entity/http_e_f_fdata_ceuropa_ceu_fw21_f7661a4a0_bbdf9_b4e98_bb04a_b967c6a1053f9") INTEROPERABILITY SALIENCY: IoP Dimension: Governance IoP The Public Service Consumer Agent is salient for organisational interoperability because it acts on behalf of a Public Service Consumer (the "Principal") to consume a Public Service. An agent is described by the tuple <agent_type, principal_type>, where agent_type belongs to {human, machine}, and principal_type belongs to {citizen, business, PA}. EXAMPLES: Your Europe Advice – ECAS Your Europe Advice is an EU advice service provided by legal experts from ECAS (European Citizen Action Service) operating under contract with the European Commission. It consists of a team of about 60 lawyers who cover all 24 official EU languages and are familiar both with EU law and national laws in all EU countries. Your Europe Advice replies to questions from citizens or businesses on their personal EU rights. The experts respond to the questions within one week, free of charge and in the language chosen by the user. ECAS’ mission is to empower citizens to exercise their rights and promote open and inclusive decision-making through the provision of high quality advice, research and advocacy, as well as capacity building for civil society organisations. Source: (http://ecas.org/services/your-europe-advice-yea/) DEFINITION: Public Service Delivery Agent ABB is a Business Role delivering a public service on behalf of a principal. Source: definition of Agent class in ISA2 Core Vocabularies (https://joinup.ec.europa.eu/catalogue/distribution/cpsv-ap-specification-v20-pdf) INTEROPERABILITY SALIENCY: IoP Dimension: Governance IoP The Public Service Delivery Agent is salient for organisational interoperability because it acts on behalf of a Public Service Provider (the "Principal") to deliver a Public Service. An agent is described by the tuple <agent_type, principal_type>, where agent_type belongs to {human, machine}, and principal_type belongs to {citizen, business, PA}. EXAMPLES: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Your Europe Advice – ECAS Your Europe Advice is an EU advice service provided by legal experts from ECAS (European Citizen Action Service) operating under contract with the European Commission. It consists of a team of about 60 lawyers who cover all 24 official EU languages and are familiar both with EU law and national laws in all EU countries. Your Europe Advice replies to questions from citizens or businesses on their personal EU rights. The experts respond to the questions within one week, free of charge and in the language chosen by the user. ECAS’ mission is to empower citizens to exercise their rights and promote open and inclusive decision-making through the provision of high quality advice, research and advocacy, as well as capacity building for civil society organisations. Source: (http://ecas.org/services/your-europe-advice-yea/) DEFINITION: Public Service Provider ABB is a Business Role deliverying public services. Source: IATE (http://iate.europa.eu/) INTEROPERABILITY SALIENCY: IoP Dimension: Governance IoP The Public Service Provider ABB is salient for organisational interoperability because it is one of the main actors involved in the interoperability of the public service as stated in the EIF: ""Service orientation, upon which the conceptual model for public services is conceived, means that the relationship between service providers and service consumers must be clearly defined. EIF Recommendation 29 also suggests: "Clarify and formalise your organisational relationships for establishing and operating European public services." EXAMPLES: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Ecolabel - Member State Competent Body The Competent Body is the independent organisation responsible for assessing, awarding, and managing EU Ecolabel applications and licences on the national level. The Competent Body provides guidance on the documents needed for the dossier, such as declarations, data sheets, and test results. Recommendations on product testing laboratories that are ISO 17025 accredited or equivalent are shared, along with any relevant technical expertise needed to complete the application. Upon application approval, the Competent Body issues the contract and licence upon approving the application. This contract sets out the services or range of products covered within the licence, including any trade names or manufacturer’s internal reference numbers. It will also lay out the terms of use of the EU Ecolabel, following the standard contract in Annex IV of the Regulation (EC) No 66/2010 of 25 November 2009. Once the contract has been signed, a certificate can be asked for/will be sent, depending on the Competent Body. This certificate will detail: the licence number that can be used with the EU Ecolabel logo; the legal name of the applicant; the services or range of products awarded the EU Ecolabel; all relevant trade names under which the product is sold or the service is marketed. The Competent Body will give the final validation on when the EU Ecolabel logo and the licence number can be used on the EU Ecolabel services and products that have met the criteria. Source: (http://ec.europa.eu/environment/ecolabel/how-to-apply-for-eu-ecolabel.html) (http://ec.europa.eu/environment/ecolabel/competent-bodies.html#be) DESCRIPTION: It is a service of general interest that public authorities of the EU member countries classify as being of general interest and, therefore, subject to specific public service obligations. They can be provided either by the state or by the private sector and they can be consumed both by the Public or by internally to the Organisation. Based on the definitions Services of general interest: https://ec.europa.eu/info/topics/single-market/services-general-interest_en INTEROPERABILITY SALIENCY: Not applicable EXAMPLES: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): EUROPASS2 - Make better use of skills and opportunities across Europe Europass is a service to help individuals to communicate their skills, qualifications and experience through the use of standardised documents templates. http://ec.europa.eu/social/main.jsp?catId=1266&langId=en DESCRIPTION: It is an interoperable public service provisioned via a digital service delivery mode by, or on behalf of, a public administration in support to the realization of a Public Administration digital business capability . An European digital public service comprises any digital public service exposed to a cross-border dimension in the Union. Sources: EIF, ISA2 Core Vocabularies, IMM http://eur-lex.europa.eu/resource.html?uri=cellar:2c2f2554-0faf-11e7-8a35-01aa75ed71a1.0017.02/DOC_3&format=PDF https://joinup.ec.europa.eu/catalogue/distribution/cpsv-ap-specification-v20-pdf https://joinup.ec.europa.eu/sites/default/files/imm_guideline_1.pdf https://ec.europa.eu/isa2/actions/assessing-progress-being-made-towards-interoperability_en INTEROPERABILITY SALIENCY: IoP Dimension: Structural IoP, Behavioral IoP, Governance IoP The Public Service ABB is salient for organisational interoperability because it is the central element around which interoperabilty needs to be ensured, as stated in the EIF: "The European Interoperability Framework is a commonly agreed approach to the delivery of European public services in an interoperable manner". EXAMPLES: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): EUROPASS2 - Make better use of skills and opportunities across Europe Europass is a service to help individuals to communicate their skills, qualifications and experience through the use of standardised documents templates. http://ec.europa.eu/social/main.jsp?catId=1266&langId=en DESCRIPTION: It is a legal resource on governance rules enabling collaboration between digital public services cross legal jurisdictions. Generally speaking it is of a generic not binding nature like the declarations of Tallinn and Berlin (typically involving many legal jurisdictions). Legal agreements of binding nature typically take the form of binding legal acts like the reference list of offences punishable in the European arrest warrant (2002/584/JHA: Council Framework Decision of 13 June 2002). Based on EIF: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex%3A12016E207 INTEROPERABILITY SALIENCY: Not applicable EXAMPLES: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): An example of a treaty that does have provisions for further binding agreements is the UN Charter. By signing and ratifying the Charter, countries agreed to be legally bound by resolutions passed by UN bodies such as the General Assembly and the Security Council. Thus, UN resolutions are legally binding on UN Member States, and no signature or ratification is necessary. Definition: Digital Public Service Machine Agent ABB is a Business Actor defined as the system that is designed to automate and improve the delivery of public services to citizens. Source: Inspired on the information available in Digital Public Services in the Digital Economy and Society Index Source reference: https://digital-strategy.ec.europa.eu/en/policies/desi-digital-public-services Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/DigitalPublicServiceMachineAgentBusinessActor LOST view: Organisational view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:DigitalPublicServiceMachineAgentBusinessActor Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Digital Public Administration Facsheet (https://joinup.ec.europa.eu/sites/default/files/inline-files/DPA_Factsheets_2022_France_vFinal_0.pdf) or the Spanish public administration digitalization plan (https://portal.mineco.gob.es/RecursosArticulo/mineco/ministerio/ficheros/210902-digitalisation-of-public-admin-plan.pdf) Interoperability Saliency: The Digital Public Service Machine Agent ABB is salient for organizational and behavioural interoperability because it permits the identification of procedures and business rules related to digital services of public administrations. This identification and consensus will facilitate the exchange of data, information and knowledge between machine-to-machine and machine-to-human interactions. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/DigitalPublicServiceMachineAgentBusinessActor EIF Layer: Organisational Definition: Digital Public Service Human Agent ABB is a Business Actor representing a stakeholder who works in the public service sector and uses digital technologies to improve the delivery of public services to citizens. This agent has the potential to improve the accessibility, efficiency, and quality of public services, ultimately leading to better outcomes for citizens and society as a whole. Source: Inspired on the information available in Digital Public Services in the Digital Economy and Society Index Source reference: https://digital-strategy.ec.europa.eu/en/policies/desi-digital-public-services Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/DigitalPublicServiceHumanAgentBusinessActor LOST view: Organisational view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:DigitalPublicServiceHumanAgentBusinessActor Example: The following implemenation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): OECD Goverment as a Glance (https://www.oecd.org/gov/government-at-a-glance-22214399.htm) Interoperability Saliency: The Digital Public Service Human Agent ABB is salient for organizational and behavioural interoperability because it permits the identification of procedures and business rules related to human interactions in public administration. This identification and consensus will facilitate the exchange of data, information and knowledge between public services and human stakeholders. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/DigitalPublicServiceHumanAgentBusinessActor EIF Layer: Organisational Definition: Digital Public Service Delivery Model ABB is a Business Collaboration representing a collection of concepts related to the way in which the public sector delivers digital technologies to citizens and businesses. Source: OECD Source reference: https://www.oecd-ilibrary.org/docserver/gov_glance-2017-72-en.pdf?expires=1649771036&id=id&accname=guest&checksum=15BFD2F7E916921236CCF160605A6430 Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/DigitalPublicServiceDeliveryModelBusinessCollaboration LOST view: Organisational view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:DigitalPublicServiceDeliveryModelBusinessCollaboration Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): OECD Public service design and delivery in the digital age (https://www.oecd-ilibrary.org/sites/3252a73a-en/index.html?itemId=/content/component/3252a73a-en) Interoperability Saliency: Digital Public Service Delivery Model ABB is salient for organizational and behavioural interoperability due to it permits to (i) reuse and share common digital services across different public administrations to deploy and publish digital services, (ii) establish common business procedures to elaborate and form the digital services for public administration, (iii) the maintenance procedures to make available such digital services. Interoperability Dimension: Structural IoP Viewpoint: Highlevel viewpoint Additional identifier: http://data.europa.eu/dr8/DigitalPublicServiceDeliveryModelBusinessCollaboration EIF Layer: Organisational Definition: Digital Public Service Provision ABB is a Business Function representing the delivery of services through digital channels aiming at incresing transparency, efficiency and responsiveness of public organizations Source: [OECD, Springer, EC Digital Public Service Provision Needs document] Source reference: [https://www.oecd-ilibrary.org/docserver/gov_glance-2017-72-en.pdf?expires=1649771036&id=id&accname=guest&checksum=15BFD2F7E916921236CCF160605A6430, https://joinup.ec.europa.eu/collection/better-legislation-smoother-implementation/document/digital-public-service-provision-needs-digitally-compatible-law-modular-concept-income, https://link.springer.com/chapter/10.1007/978-3-030-91247-5_3] Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/DigitalPublicServiceProvisionBusinessFunction LOST view: Organisational view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:DigitalPublicServiceProvisionBusinessFunction Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): The Spanish Tax Agency is responsible for providing Digital Public Services on TAX payment. https://sede.agenciatributaria.gob.es/Sede/en_gb/iva.html Interoperability Saliency: The Digital Public Service Provision ABB is salient for organizational and semantic interoperability because it offers (i) mechanisms to exchange information transparently; (ii) manage the information with needed security and trust; (iii) combine and harmonise information coming from multiple data stores to give service to the different agents (or stakeholders) Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/DigitalPublicServiceProvisionBusinessFunction EIF Layer: Organisational Definition: Digital Public Service Delivery ABB is a Business Interface representing the way in which the public sector delivers digital technologies and public services to citizens and businesses. Source: OECD Source reference: https://www.oecd-ilibrary.org/docserver/gov_glance-2017-72-en.pdf?expires=1649771036&id=id&accname=guest&checksum=15BFD2F7E916921236CCF160605A6430 Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/DigitalPublicServiceDeliveryBusinessInterface LOST view: Organisational view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:DigitalPublicServiceDeliveryBusinessInterface Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): The Spanish Tax Agency is responsible for providing Digital Public Services on TAX payment. https://sede.agenciatributaria.gob.es/Sede/en_gb/iva.html Interoperability Saliency: The Digital Public Service Delivery ABB is a key interoperability enabler (*) for organizational and semantic interoperability because it defines the mechanism to deliver digital services in terms of (i) establishing a mechanism to interact with the data; (ii) establishing rules to validate the data and procedures; and (iii) provide a transparent response to the different petitions from the stakeholders. Interoperability Dimension: Behavioral IoP Viewpoint: Highlevel viewpoint Additional identifier: http://data.europa.eu/dr8/DigitalPublicServiceDeliveryBusinessInterface EIF Layer: Organisational Definition: Mobile APP ABB is a Business Interface that corresponds to a computer program designed to run on a mobile device, such as a smartphone or tablet Source: ISO/IEC 29179:2012 Source reference: https://www.iso.org/standard/45258.html Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/MobileAppBusinessInterface LOST view: Organisational view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:MobileAppBusinessInterface Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): EU Council mobile app. https://play.google.com/store/apps/details?id=eu.europa.publications.eucouncil&hl=en_US&gl=US&pli=1 Interoperability Saliency: Mobile App ABB is salient for organizational, semantic and technical interoperability because it offers (i) a visual environment to interact with the public service procedures and data; (ii) an understanding of the information to be represented; and (iii) an elaborate mechanism to exchange data with public services. Interoperability Dimension: Behavioral IoP Additional identifier: http://data.europa.eu/dr8/MobileAppBusinessInterface EIF Layer: Organisational Definition: Desktop APP ABB is a Business Interface that corresponds to a computer program designed to run on a desktop or laptop computer, typically with a graphical user interface (GUI) Source: Inspired in "Information Technology and Computer Applications in Public Administration" book Source reference: ISBN 978-81-317-3309-7 Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/DesktopAppBusinessInterface LOST view: Organisational view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:DesktopAppBusinessInterface Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Electronic Invoice Management Desktop Application, The Electronic Invoice Management desktop application developed by the Ministry of Industry, Energy and Tourism is used to create electronic invoices in the Facturae format (Order PRE/2971/2007) in an easy and simple way. Developed with open-source software, this application is targeted at micro-, small- and medium-sized enterprises (SMEs) and freelance workers, solving the problems associated with the storage of paper invoices. https://joinup.ec.europa.eu/collection/spain-center-technology-transfer/solution/electronic-invoice-management-desktop-application/about Interoperability Saliency: Desktop App ABB is salient for organizational, semantic and technical interoperability because it offers (i) a visual environment to interact with the public service procedures and data; (ii) an understanding of the information to be represented; and (iii) an elaborate mechanism to exchange data with public services. Interoperability Dimension: Behavioral IoP Additional identifier: http://data.europa.eu/dr8/DesktopAppBusinessInterface EIF Layer: Organisational Definition: Service APP ABB is a Business Interface is a a type of software application that provides specific functionality to other applications or users within a larger system. Service applications are designed to operate in the background and provide specific services, such as database access, messaging, authentication, or other functionality, to other applications that require those services Source: Inspired in ETSI TR 103 290 Source reference: https://www.etsi.org/deliver/etsi_tr/103200_103299/103290/01.01.01_60/tr_103290v010101p.pdf Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/ServiceAppBusinessInterface LOST view: Organisational view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:ServiceAppBusinessInterface Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): EUROTRACE is a powerful and flexible software application that provides the structures and tools for the management of statistical data. EUROTRACE can be used as a production system for the integration, validation and management of statistical datasets and can be used with the following DBMS: MS ACCESS, ORACLE, SQL Server. https://joinup.ec.europa.eu/sites/default/files/document/2014-04/Eurotrace%20DBMS%202.6%20UG_EN.pdf Interoperability Saliency: Service App ABB is salient for organizational, semantic and technical interoperability because it establishes the mechanisms to provide data and services to public service consumers. The Service App ABB will identify and implement needed mechanisms to (i) deliver data according to the digital service procedures, and (ii) enable service and data discovery. Interoperability Dimension: Behavioral IoP Additional identifier: http://data.europa.eu/dr8/ServiceAppBusinessInterface EIF Layer: Organisational Definition: Web APP ABB is a Business Interface that corresponds to a computer program that runs on a web browser and is accessible through the internet Source: ISO/IEC/IEEE 23026:2015 Source reference: https://www.iso.org/obp/ui/#iso:std:iso-iec-ieee:23026:ed-1:v1:en Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/WebAppBusinessInterface LOST view: Organisational view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:WebAppBusinessInterface Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Digital Signature Service (DSS) Web Application. https://ec.europa.eu/digital-building-blocks/DSS/webapp-demo/home Interoperability Saliency: Web App ABB is salient for organizational, semantic and technical interoperability because it offers (i) a visual environment to interact with the public service procedures and data; (ii) an understanding of the information to be represented; and (iii) an elaborate mechanism to exchange data with public services. Interoperability Dimension: Behavioral IoP Additional identifier: http://data.europa.eu/dr8/WebAppBusinessInterface EIF Layer: Organisational Definition: Adaptive Configuration ABB is a Business Interface that refers to the ability of a system or application to dynamically adjust its settings or configuration based on changing conditions or user preferences. This allows the system to optimize its performance and adapt to different environments or situations. Source: INSPIRED in Science Direct Source reference: https://www.sciencedirect.com/topics/engineering/adaptive-systems Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/AdaptiveConfigurationBusinessInterface LOST view: Organisational view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:AdaptiveConfigurationBusinessInterface Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): An example of adaptive configuration is the automatic configuration that mobile phones include to keep the signal for using mobile data. Another aspect that is also related to Data is the "Adaptive Data Rate" Adaptive Data Rate (ADR) is a mechanism for optimizing data rates, airtime and energy consumption in the network. The ADR mechanism controls the following transmission parameters of an end device: 1. Spreading factor; 2. Bandwidth; 3. Transmission power. https://www.thethingsnetwork.org/docs/lorawan/adaptive-data-rate/ Interoperability Saliency: Adaptive Configuration ABB is salient for organizational, semantic and technical interoperability because it establishes the mechanism to adapt the procedures and data delivery according to the data consumption needs. Interoperability Dimension: Behavioral IoP Additional identifier: http://data.europa.eu/dr8/AdaptiveConfigurationBusinessInterface EIF Layer: Organisational Definition: Legislation on Digital Public Services ABB is a Business formalising a set of rules and requirements concerning digital public services. Source: Inspired on the content of the Digital Services Act package Source reference: https://digital-strategy.ec.europa.eu/en/policies/digital-services-act-package Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/LegislationOnDigitalPublicServicesBusinessObject LOST view: Legal view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:LegislationOnDigitalPublicServicesBusinessObject Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): The binding and non-binding legislation produced towards the Digital Single Market. https://www.consilium.europa.eu/en/policies/digital-single-market/), and any of the national efforts towards the alignment to the European Digital Strategy (e.g., DigitalES in Europe (https://www.digitales.es/en/digitales-in-europe/ Interoperability Saliency: The Legislation on Digital Public Services ABB is salient for the governance, behavioural and structural interoperability because it sets rules that relate specifically to i) the reuse of solutions in the context of digital public services, ii) the exchange of digital data, information and knowledge, and iii) the collaboration amongst the public administrations' digital services. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/LegislationOnDigitalPublicServicesBusinessObject EIF Layer: Legal Definition: Digital Public Service Catalogue ABB is a Business Object that enables the index of active digital public services, and their descriptions, that are provided by a public administration. This ABB is a key interoperability enabler (*) for sharing/PROVISIONING and reusing/CONSUMING of front-office public services. Source: ISA2 Core Vocabularies (https://joinup.ec.europa.eu/catalogue/distribution/cpsv-ap-specification-v20-pdf) Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/DigitalPublicServiceCatalogueBusinessObject LOST view: Organisational view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:DigitalPublicServiceCatalogueBusinessObject Synonym: Public Service Registry, Public Service Inventory Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): FEDICT service catalogue - FEDICT, part of the Federal Public Service Policy and Support of Belgium, offers a public service catalogue. Here are a few examples of the offered services: Company data (company information and certificates), Digiflow (access to online certificates), E-mail Relay (relay of e-mail to and from the federal public services and institutions, as a protection to viruses and spam), eBirth (birth online notification and transfer of statistics), eDepot (for notaries), Federal Authentication Service (authentication of individuals for access to online government applications), etc.(http://www.fedict.belgium.be/en/service_catalogue) Interoperability Saliency: The Digital Public Service Catalogue ABB is a key interoperability enabler (*) for organisational and structural interoperability by (i) ensuring the provision/consumption of front-office digital public services, and (ii) making public and discoverable catalogues of data about public services to favour the use of common models. Interoperability Dimension: Structural IoP Viewpoint: Key Interoperability Enablers viewpoint Additional identifier: http://data.europa.eu/dr8/DigitalPublicServiceCatalogueBusinessObject EIF Layer: Organisational Definition: Legislation Catalogue ABB is a Business Object creating an indexed inventory of legal documents with comprehensiveness and trustiness value. Source: IATE Source reference: http://iate.europa.eu/ Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/LegislationCatalogueBusinessObject LOST view: Legal view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:LegislationCatalogueBusinessObject Synonym: Official Journal Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): EUR-Lex - It provides the official and most comprehensive access to EU legal documents. It is available in all of the EU’s 24 official languages and is updated daily. https://eur-lex.europa.eu/content/welcome/about.html Interoperability Saliency: The Legislation Catalogue ABB is a key interoperability enabler (*) for structural and governance interoperability enablers. It is salient for structural interoperability because it supports enabling sharing/provisioning and reusing/consumption of legislation on digital public services. The Legislation Catalogue ABB is also salient for the governance of interoperability because it compiles the legislation that needs to be discovered and applied for collaboration with other public administrations' digital public services, either because it is binding or because it is a source of strong recommendations. Additional information: DECISION (EU) 2015/2240 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 25 November 2015 establishing a programme on interoperability solutions and common frameworks for European public administrations, businesses and citizens (ISA2 programme) as a means for modernising the public sector. Interoperability Dimension: Structural IoP Viewpoint: Key Interoperability Enablers viewpoint Additional identifier: http://data.europa.eu/dr8/LegislationCatalogueBusinessObject EIF Layer: Legal Definition: Interoperability Dimension ABB is a Business Object enabling peer-to-peer collaboration with [public] services towards mutually beneficial goals, involving the exchange of data, information and knowledge between them regardless their legal, organisational, semantical and technical environment. Source: European Commission, ISA Programme. Source reference: (https://ec.europa.eu/isa2/sites/default/files/eif_brochure_final.pdf) Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Interoperability is of multidimensional nature involving structural interoperability, behavioural interoperability and governance interoperability: - The structural interoperability is “the extent its structure has been developed reusing and/or sharing components in support of a peer-to-peer collaboration”; - The behavioural interoperability is “the extent its manifested behaviour exchanges data, information or knowledge with its environment in support of a peer-to-peer collaboration”; - The governance interoperability is “the extent its agreed choreography rules support a peer-to-peer collaboration. Identifier: http://data.europa.eu/dr8/InteroperabilityDimensionBusinessObject eira:ID: ABB363 ABB name: eira:InteroperabilityDimensionBusinessObject Last modification: 2022-23-01 Definition: Interoperability Framework ABB is a Business Object that enables interoperability to organisations that wish to collaborate towards the joint delivery of public services. Within its scope of applicability, it specifies a set of common elements such as vocabulary, concepts, principles, guidelines, and recommendations. Source: ISA2, EIFv2 Source reference: (https://ec.europa.eu/isa2/isa2_en) Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/InteroperabilityFrameworkBusinessObject LOST view: Organisational view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:InteroperabilityFrameworkBusinessObject Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): The new European Interoperability Framework (EIF) - The new European Interoperability Framework (EIF) is part of the Communication (COM(2017)134) from the European Commission adopted on 23 March 2017. The framework gives specific guidance on how to set up interoperable digital public services. It offers public administrations 47 concrete recommendations on how to improve governance of their interoperability activities, establish cross-organisational relationships, streamline processes supporting end-to-end digital services, and ensure that both existing and new legislation do not compromise interoperability efforts. The new EIF is undertaken in the context of the Commission priority to create a Digital Single Market in Europe. The public sector, which accounts for over a quarter of total employment and represents approximately a fifth of the EU’s GDP through public procurement, plays a key role in the Digital Single Market as a regulator, services provider and employer. The successful implementation of the EIF will improve the quality of European public services and will create an environment where public administrations can collaborate digitally. (https://ec.europa.eu/isa2/eif_en) Interoperability Saliency: The Interoperability Framework ABB is salient for organizational interoperability because it determines a set of rules, practices and a commonly agreed approach to the delivery of European public services. Interoperability Dimension: Governance IoP Viewpoint: Interoperability Governance viewpoint Additional identifier: http://data.europa.eu/dr8/InteroperabilityFrameworkBusinessObject EIF Layer: Organisational Definition: Security Policy ABB is a Business Object that regulates the protection of customer or client's data. Source: Gartner Source reference: https://www.gartner.com/en/information-technology/glossary/security Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/SecurityPolicyBusinessObject LOST view: Semantic view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:SecurityPolicyBusinessObject Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Common Foreign and Security Policy (CFSP) - The Common Foreign and Security Policy (CFSP) is the organised, agreed foreign policy of the European Union (EU) for mainly security and defence diplomacy and actions. https://eeas.europa.eu/topics/common-foreign-security-policy-cfsp_en Interoperability Saliency: The Security Policy ABB is salient for semantic interoperability because it provides a guiding framework to ensure the security of data and information according to interoperability principles as stated in the EIF recommendation n° 46 and 47: "Consider the specific security and privacy requirements and identify measures for the provision of each public service according to risk management plans." Interoperability Dimension: Governance IoP Viewpoint: Interoperability Security viewpoint Additional identifier: http://data.europa.eu/dr8/SecurityPolicyBusinessObject EIF Layer: Semantic Definition: Privacy Policy ABB is a Business Object that regulates the personal data of any customer, client or employee inforamtion. Source: EU Data Protection Source reference: https://commission.europa.eu/law/law-topic/data-protection_en Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/PrivacyPolicyBusinessObject LOST view: Semantic view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:PrivacyPolicyBusinessObject Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Protection of individuals with regard to the processing of personal data - GDPR. https://eira-si.eu/privacy-policy/ Interoperability Saliency: The Privacy Policy ABB is salient for semantic interoperability because it provides a guiding framework to ensure the privacy of data and information according to interoperability principles as stated in the EIF recommendation n° 46 and 47: "Consider the specific security and privacy requirements and identify measures for the provision of each public service according to risk management plans." Interoperability Dimension: Governance IoP Viewpoint: Interoperability Governance viewpoint Additional identifier: http://data.europa.eu/dr8/PrivacyPolicyBusinessObject EIF Layer: Semantic Definition: EIF Interoperability Level ABB is a Business Object setting guidelines for developing public services. The EIF defines four interoperability levels, which cover legal, organisational, semantic and technical interoperability. Each level deserves special attention when a new European public service is established. Source: European Commission, ISA Programme. The New European Interoperability Framework (EIF) for European public services. [Online] 2017 Source reference: (https://ec.europa.eu/isa2/eif_en.) Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): The EIF defines four interoperability levels, which cover legal, organisational, semantic and technical interoperability. Identifier: http://data.europa.eu/dr8/EifInteroperabilityLevelBusinessObject eira:ID: ABB340 ABB name: eira:EifInteroperabilityLevelBusinessObject Last modification: 2022-23-01 Definition: Open Data Policy ABB is a Business Object formalising the procedures to publish FAIR data generated by different parties. FAIR data means being aligned and compliant with FAIR principles, making data Findable, Accessible, Interoperable, and Reusable. Source: EU Open Data guide Source reference: http://bookshop.europa.eu/en/eu-open-data-pbOA0416036/downloads/OA-04-16-036-EN-C/OA0416036ENC_002.pdf?FileName=OA0416036ENC_002.pdf&SKU=OA0416036ENC_PDF&CatalogueNumber=OA-04-16-036-EN-C Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/OpenDataPolicyBusinessObject LOST view: Semantic view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:OpenDataPolicyBusinessObject Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): EU implementation of the G8 Open Data Charter. https://ec.europa.eu/digital-single-market/en/news/eu-implementation-g8-open-data-charter Interoperability Saliency: The Open Data Policy ABB is salient for semantic interoperability because Open Data is a part of the basic components of the EIF's conceptual model for integrated public services. Opening of public sector datasets for sharing and reuse is encouraged by the Directive on the reuse of public sector information, which provides a common legal framework for reuse of public sector data as stated in the EIF recommendation n° 2: "Publish the data you own as open data unless certain restrictions apply." Additional information: Open Data Policyspecifically refers to publish (raw) data in a way that is accessible, reusable, findable, machine readable and licensed permissively. It can be generated by a wide range of parties, including public authorities, the semi-public sector, businesses and the public. In the case of public authorities, such as European Union organisations, making their data available for public reuse supports economic development, openness and transparency. Interoperability Dimension: Governance IoP Viewpoint: Interoperability Governance viewpoint Additional identifier: http://data.europa.eu/dr8/OpenDataPolicyBusinessObject EIF Layer: Semantic Definition: Legislation on Data information and Knowledge Exchange ABB is a Business Object that refers to the legal basis, rules and agreements that regulate how data is shared, accessed and used amng different actors and systems. Source: Inspired in EIF Source reference: https://eur-lex.europa.eu/resource.html?uri=cellar:2c2f2554-0faf-11e7-8a35-01aa75ed71a1.0017.02/DOC_1&format=PDF Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/LegislationOnDataInformationAndKnowledgeExchangeBusinessObject LOST view: Legal view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:LegislationOnDataInformationAndKnowledgeExchangeBusinessObject Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Commission Regulation (EU) 2015/703 of 30 April 2015 establishing a network code on interoperability and data exchange rules (Text with EEA relevance) http://data.europa.eu/eli/reg/2015/703/oj Interoperability Saliency: The Legislation on Data Information and knowledge exchange ABB is a key interoperability enabler (*) for the governance, behavioural, structural and semantic interoperability because it sets rules that relate specifically to i) the reuse of solutions in the context of digital public services, ii) the exchange of digital data, information and knowledge, iii) the collaboration amongst the public administrations' digital services, and iv) the determination of standard data exchange models to facilitate data harmonization. Interoperability Dimension: Behavioral IoP Viewpoint: Key Interoperability Enablers viewpoint Additional identifier: http://data.europa.eu/dr8/LegislationOnDataInformationAndKnowledgeExchangeBusinessObject EIF Layer: Legal Definition: Data Portability Policy ABB is a Business Object that regulates data reuse and data transference between public administrations. Source: GDPR Source reference: https://gdpr.eu/recital-68-right-of-data-portability/ Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/DataPortabilityPolicyBusinessObject LOST view: Semantic view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:DataPortabilityPolicyBusinessObject Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Italy implementation of the Art. 68 of the EU General Data Protection Regulation (GDPR). https://www.garanteprivacy.it/regolamentoue/guida-all-applicazione-del-regolamento-europeo-in-materia-di-protezione-dei-dati-personali Interoperability Saliency: The Data Portability Policy ABB is salient for semantic interoperability because it regulates how data can be exchanged and its reuse. Additional information: This ABB implements the right to data portability, which is one of eight rights enforced by the EU General Data Protection Regulation (GDPR). It regulates the exchange of data, allowing data subjects to obtain data that a data controller holds on them and to reuse it for their own purposes. Accourding to GDPR, Individuals are free to either store the data for personal use or to transmit it to another data controller. The data must be received “in a structured, commonly used and machine-readable format”. Interoperability Dimension: Governance IoP Viewpoint: Interoperability Governance viewpoint Additional identifier: http://data.europa.eu/dr8/DataPortabilityPolicyBusinessObject EIF Layer: Semantic Definition: Security Framework ABB is a Business Object that enables the protection of various aspects of data, information and knowledge assets and the organizational resources handling them. Source: Inspired in the works by ISA2, and the EIF-related works Source reference: https://ec.europa.eu/isa2/isa2_en Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/SecurityFrameworkBusinessObject LOST view: Organisational view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:SecurityFrameworkBusinessObject Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): The EU cybersecurity certification framework - The European Commission puts forward the creation of a EU certification framework for ICT security products in its 2017 proposal for a regulation. - On 13 September 2017 the Commission issued a proposal for a regulation on ENISA, the ""EU Cybersecurity Agency"", and on Information and Communication Technology cybersecurity certification (''Cybersecurity Act''). Certification plays a critical role in increasing trust and security in products and services that are crucial for the digital single market. At the moment, a number of different security certification schemes for ICT products exist in the EU. Without a common framework for EU-wide valid cybersecurity certificates, there is an increasing risk of fragmentation and barriers in the single market. The proposed certification framework will provide EU-wide certification schemes as a comprehensive set of rules, technical requirements, standards and procedures. This will be based on agreement at EU level for the evaluation of the security properties of a specific ICT-based product or service e.g. smart cards. The certification will attest that ICT products and services that have been certified in accordance with such a scheme comply with specified cybersecurity requirements. The resulting certificate will be recognized in all Member States, making it easier for businesses to trade across borders and for purchasers to understand the security features of the product or service. The schemes proposed in the future European framework will rely as much as possible on international standards as a way to avoid creating trade barriers and ensuring coherence with international initiatives." Interoperability Saliency: The Security Framework ABB is salient for legal and organizational interoperability due to it permits the establishment of security and privacy procedures and rules to determine the provision of public services. This framework will provide secure and trustworthy data exchange between public administrations and in interactions with citizens and businesses. Interoperability Dimension: Governance IoP Viewpoint: Interoperability Security viewpoint Additional identifier: http://data.europa.eu/dr8/SecurityFrameworkBusinessObject EIF Layer: Organisational Definition: Data Policy ABB is a Business Object aiming to form the guiding framework in which data management can operate. Source: OECD Source reference: https://stats.oecd.org/glossary/detail.asp?ID=4454 Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/DataPolicyBusinessObject LOST view: Semantic view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:DataPolicyBusinessObject Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): EU SCIENCE HUB - The European Commission's science and knowledge service - JRC's Data policy: The JRC's data policy is driven by transparency with the aim of contributing to innovation. It is a pillar of the development and implementation of scientific knowledge management at the JRC. It follows the commitments and regulatory basis of the Commission Decision on the reuse of Commission documents (2011/833/EU). The objectives for adopting and implementing the JRC data policy include: • Share and use data on the basis of the JRC Open Data principles: fully, freely, openly and timely; • To be transparent on the reasons for restricted access to certain data; • Provide a coordinated approach to the acquisition of data by the JRC; • Facilitate management, broaden access and use of JRC data; • Reinforce goals of Horizon 2020; • Support EU implementation of the G8 Open Data Charter; • Continuously support evidence-based decision making and research; • Ensure that JRC data is made available through the EU Open Data Portal. For a successful implementation process, the JRC's data policy lays down implementation principles with respect to responsible entities, overall implementation guidelines, and their individual elements like data management plans, as well as the monitoring of its implementation. https://ec.europa.eu/jrc/en/about/jrc-in-brief/data-policy Interoperability Saliency: The Data Policy ABB is salient for semantic interoperability because it provides a guiding framework to manage data and information according to interoperability principles as stated in the EIF recommendation n° 30: "Perceive data and information as a public asset that should be appropriately generated, collected, managed, shared, protected and preserved." Interoperability Dimension: Governance IoP Viewpoint: Interoperability Privacy viewpoint Additional identifier: http://data.europa.eu/dr8/DataPolicyBusinessObject EIF Layer: Semantic Definition: Conformance Test Scenario ABB is a Business Object specifying a sequence of actions for the execution of a test. Also known as a test script or manual test script. Source: NIST Source reference: https://www.nist.gov/itl/ssd/information-systems-group/overview-conformance-testing Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/ConformanceTestScenarioBusinessObject LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:ConformanceTestScenarioBusinessObject Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): SoapUI - SoapUI is the world's most widely-used open source API testing tool for SOAP and REST APIs. SoapUI offers SOAP Web Services functional testing, REST API functional testing, WSDL coverage, message assertion testing and test refactoring. Scenario-based tests should be directly tied to user stories, which were probably provided by the product owner or some business stakeholder. Under ideal circumstances, these tests should be the user stories, so that business stakeholders can both easily help the tester develop the test cases and understand the results. [https://www.soapui.org/testing-dojo/best-practices/scenario-based-testing.html][https://www.soapui.org/testing-dojo/world-of-api-testing/test-first.html] Interoperability Saliency: The Conformance Testing Scenario ABB  is salient for technical interoperability because it provides a document of a list of activities for the execution of interoperability tests. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/ConformanceTestScenarioBusinessObject EIF Layer: TechnicalApplication Definition: Digital Governance ABB is a Business Object that ensures the functioning of an Interoperability Framework. These rules include structures, roles, responsibilities, policies, standards, specifications, practices, decision making and operational procedures. Source: EIF Source reference: http://eur-lex.europa.eu/resource.html?uri=cellar:2c2f2554-0faf-11e7-8a35-01aa75ed71a1.0017.02/DOC_3&format=PDF Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/DigitalGovernancePlanBusinessObject LOST view: Organisational view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:DigitalGovernancePlanBusinessObject Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): The INSPIRE Directive 2007/2/EC of 14 March 2007, Article 18. Member States shall ensure that appropriate structures and mechanisms are designated for coordinating, across the different levels of government, the contributions of all those with an interest in their infrastructures for spatial information. These structures shall coordinate the contributions of, inter alia, users, producers, added-value service providers and coordinating bodies, concerning the identification of relevant data sets, user needs, the provision of information on existing practices and the provision of feedback on the implementation of this Directive. (http://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32007L0002&from=EN) Interoperability Saliency: The Digital Governance Plan ABB is salient for governance and organizational interoperability because it helps to (i) establish and holistic approach to data exchange and management, and (ii) determine the common instruments to achieve interoperability across administrative levels and sectors. Additional information: Plans are in principle narrower and more detailed than Digital Agendas, and as a matter of fact they are intended to drill down and realise a global agenda. For an additional example of plan focused on interoperability, see the Governance Plan defined in the new European Interoperability Framework (EIF) - § 3.1 of the new EIF Annex II: Interoperability governance refers to decisions on interoperability frameworks, institutional arrangements, organisational structures, roles and responsibilities, policies, agreements and other aspects of ensuring and monitoring interoperability at national and EU levels. The European interoperability framework, the Interoperability Action Plan (Annex 1 to the Communication) and the European interoperability architecture (EIRA) are important parts of interoperability governance at the EU level. (http://eur-lex.europa.eu/resource.html?uri=cellar:2c2f2554-0faf-11e7-8a35-01aa75ed71a1.0017.02/DOC_3&format=PDF) Interoperability Dimension: Governance IoP Viewpoint: Interoperability Governance viewpoint Additional identifier: http://data.europa.eu/dr8/DigitalGovernancePlanBusinessObject EIF Layer: Organisational Definition: Master Data Policy ABB is a Business Object being applied to the authoritative, most accurate data that is available about key business entities, used to establish the context for business transactions and transactional data. Source: DAMA DM_BOK Source reference: http://www.dama.org Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/MasterDataPolicyBusinessObject LOST view: Semantic view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:MasterDataPolicyBusinessObject Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): EMVO: EMVS Master Data Guide - The EMVS (European Medicines Verification System) requires that OBP’s (OnBoarding Partners) upload both product master data and product batch/pack data. The aim of this guide is to clarify what data is expected to be used for the EMVS master data noting that the long-term goal is to source directly from the IDMP/SPOR system. https://emvo-medicines.eu/new/wp-content/uploads/EMVO_0122_EMVS-Master-Data-Guide-1.pdf Interoperability Saliency: The Master Data Policy ABB is salient for semantic interoperability because Master Data is used to establish the context for business transactions and transactional data by providing accurate data usually stored and available for reuse by other parties. Its management should be prioritised as stated in the EIF recommendation n° 31: "Put in place an information management strategy at the highest possible level to avoid fragmentation and duplication. Management of metadata, master data and reference data should be prioritised." Interoperability Dimension: Governance IoP Viewpoint: Interoperability Governance viewpoint Additional identifier: http://data.europa.eu/dr8/MasterDataPolicyBusinessObject EIF Layer: Semantic Definition: Privacy Framework ABB is a Business Object that enables the confidentiality aspects of data, information and knowledge assets and organizational resources handling them. Source: Inpired in the ISA2 and EIFv2-related works Source reference: https://ec.europa.eu/isa2/isa2_en Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/PrivacyFrameworkBusinessObject LOST view: Organisational view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:PrivacyFrameworkBusinessObject Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): European Privacy Framework - European privacy legislation is made up of two parts: The Data Protection Directive (95/46/EC) exists as a common ground across Europe. The Directive is a legislative act of the European Union that requires all member states to ensure there is an "adequate" level of data protection. The second part consists of diverse national laws. (https://www.privacy-europe.com/european-privacy-framework.html) Interoperability Saliency: The Privacy Framework ABB is salient for governance and organizational interoperability because it provides the needed procedures and agreements on the establishment of privacy in public administration digital services. This framework commonly defined security and privacy actions to be considered in public digital services for ensuring secure and trustworthy data management. Interoperability Dimension: Governance IoP Viewpoint: Interoperability Privacy viewpoint Additional identifier: http://data.europa.eu/dr8/PrivacyFrameworkBusinessObject EIF Layer: Organisational Definition: Information ABB is a Business Object describing business facts, assets, or opinions that are exchanged in the context of a digital public service to support its delivery. Information is enacted via interpretation rules (expressed in an ontology) of data and considering knowledge of a given context. Examples include an invoice, a medical prescription, a driving license. Source: TOGAF guide about business capabilities, TOGAF definition of information Source reference: (https://www2.opengroup.org/ogsys/catalog/g161)), (http://pubs.opengroup.org/architecture/togaf9-doc/arch/) Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/InformationBusinessObject LOST view: Organisational view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:InformationBusinessObject Synonym: Business Facts, Business Data, Business Opinions Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Surveillance3 - Surveillance information: Published Surveillance information (Business Information) on Europa: Textile category 1 - Cotton yarn, not put up for retail sale [Council Regulation (EEC) No 3030/93] from Belarus in 2015: see URL for details(http://ec.europa.eu/taxation_customs/dds2/surv/surv_data_list.jsp?Lang=en&survNumber=670010&survType=1&startDate=20150101&originCode=BY) Interoperability Saliency: The Information ABB is salient for organisational interoperability because it represents the data being exchanged between organisations. Its interoperability needs to be guaranteed using organisational and semantic interoperability specifications. Interoperability Dimension: Behavioral IoP Viewpoint: Interoperability Privacy viewpoint Additional identifier: http://data.europa.eu/dr8/InformationBusinessObject EIF Layer: Organisational Definition: Digital-ready Policymaking ABB is a Business Process consisting in formulating digital-ready policies and legislation by considering digital aspects from the start of the policy cycle to ensure that they are ready for the digital age, future-proof and interoperable. Source: Joinup (Digital Ready Policies) Source reference: https://joinup.ec.europa.eu/collection/better-legislation-smoother-implementation/digital-ready-policymaking Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/Digital-readyPolicymakingBusinessProcess LOST view: Legal view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:Digital-readyPolicymakingBusinessProcess Synonym: Policy Cycle Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Performance-based Full Policy Cycle for the Digital Single Market (http://www.europarl.europa.eu/RegData/etudes/etudes/join/2013/507457/IPOL-IMCO_ET(2013)507457_EN.pdf). The key features of a performance-based full policy cycle are a clear articulation of policy objectives, the identification and use of quantitative indicators of expected short-term and longer-term policy impacts, the identification of synergies between policies, a much greater use of quantitative data in ex-ante impact assessments, the implementation of robust, data-based, independent ex post assessments of the performance of policies relative to their expected impacts and a wide dissemination of lessons learned in such ex-post performance assessments Interoperability Saliency: The Public Policy Cycle ABB is salient for the governance interoperability because it impacts on the design and formulation of public policies, which are implemented through legal acts. Also, the ABB also is salient for the legal interoperability due to it establis the legal actions and directives for public administration services as the case of interoperability principles need to be taken into account during the whole public policy cycle. Additional information: Policies (and legislative acts) are digital-ready if they enable smooth and digital by default policy implementation and foster digital transformation through best use of digital technologies and data. This implies that policymakers work in a multidisciplinary team and consider the following digital-ready components: 1. user-centric processes ready for automation, 2. alignment with digital policies (for example on accessibility, eID...), 3. the once-only principle and the reuse of data, 4. the evolving ICT landscape, 5. innovation and digital technologies, and 6. digital-ready drafting. Interoperability Dimension: Governance IoP Viewpoint: Enterprise Architecture Framework alignment guidelines viewpoint Additional identifier: http://data.europa.eu/dr8/Digital-readyPolicymakingBusinessProcess EIF Layer: Legal Definition: Data Holder ABB is a Business Role being assigned to a legal person, including public sector bodies and international organisations, or a natural person who is not a data subject with respect to the specific data in question, which, in accordance with applicable Union or national law, has the right to grant access to or to share certain personal data or non-personal data. Source: Data Governance Act (DGA) Source reference: http://data.europa.eu/eli/reg/2022/868/oj Last modification: 2024-04-22 Identifier: http://data.europa.eu/dr8/DataHolderBusinessRole LOST view: Organisational view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:DataHolderBusinessRole Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): In the GDPR, "controller", or "processor" on behalf of the "controller" are examples of the data owner role defined for this ABB. See GDPR https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32016R0679&from=EN , Article 4, Definitions. Interoperability Saliency: The Data Holder ABB is salient for organizational interoperability because it plays a pivotal role in facilitating data access and sharing within the framework of the Data Governance Act. This designation applies to both legal entities, such as public sector bodies and international organizations, and individuals authorized by applicable Union or national law to grant access to specific personal or non-personal data. By delineating responsibilities and ensuring compliance with regulatory standards, the identification of Data Holders fosters transparency, accountability, and alignment with data governance policies, ultimately promoting seamless data interoperability within organizational contexts Additional information: Data owners may not work with their data every day, but are responsible for overseeing and protecting a data domain. In the context of the GDPR, data owners are accountable for the quality, integrity, and protection of their data space. In SiMPL (https://digital-strategy.ec.europa.eu/en/news/simpl-cloud-edge-federations-and-data-spaces-made-simple), the data owner is the legal entity that has sovereignty over the data, usually the creator of the data or the one who executes control over the data. See SiMPL requirements and architecture vision document. The Data Governance Act does not define the concept Data Owner, but intrinsically this role can be assigned also to the Data Holder, since "holding" usually entails "controlling". Interoperability Dimension: Governance IoP Viewpoint: Interoperability Privacy viewpoint Additional identifier: http://data.europa.eu/dr8/DataHolderBusinessRole EIF Layer: Organisational Definition: Agent ABB is a Business Role defined as an Entity that is able to carry out action. Source: SEMIC-CPV or SEMIC-CCCEV Source reference: https://semiceu.github.io/Core-Person-Vocabulary/releases/2.00/#Agent Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/AgentBusinessRole LOST view: Organisational view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:AgentBusinessRole Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): foaf:Agent An agent (eg. person, group, software or physical artifact). (http://xmlns.com/foaf/0.1/#term_Agent) Interoperability Saliency: The Agent ABB is salient for organizational and behavioural interoperability because it permits the identification of procedures and business rules related to specific organizations, individuals or public services that facilitates the exchange of data, information and knowledge between digital public services. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/AgentBusinessRole EIF Layer: Organisational Definition: Digital Public Service Provider ABB is a Business Role representing the entity that offer or deliver public services using digital channels and technologies. Digital public service providers aim to provide efficient and accessible services to citizens and businesses by leveraging the power of digital technology. Source: Inspired on the information available in Digital Public Services in the Digital Economy and Society Index Source reference: https://digital-strategy.ec.europa.eu/en/policies/desi-digital-public-services Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/DigitalPublicServiceProviderBusinessRole LOST view: Organisational view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:DigitalPublicServiceProviderBusinessRole Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): The Spanish Tax Agency is responsible for providing Digital Public Services on TAX payment. https://sede.agenciatributaria.gob.es/Sede/en_gb/iva.html Interoperability Saliency: The Digital Public Service Provider ABB is salient for organizational and semantic interoperability because it offers (i) mechanisms to exchange information transparently; (ii) manage the information with needed security and trust; (iii) combine and harmonise information coming from multiple data stores to give service to the different agents (or stakeholders) Interoperability Dimension: Structural IoP Viewpoint: Interoperability Privacy viewpoint Additional identifier: http://data.europa.eu/dr8/DigitalPublicServiceProviderBusinessRole EIF Layer: Organisational Definition: Data Owner ABB is a Business Role being assigned to individual who creates or generates the data or the entity that has legal ownership or control over the data. In other cases, a data owner might be the individual or entity that is responsible for managing or overseeing the use of the data. It can be mapped with Data Controller from the GDPR, under the European General Data Protection Regulation (GDPR), a "data controller" is defined as the entity that determines the purposes, conditions, and means of the processing of personal data. This means that the data controller is the entity that decides why and how personal data is processed. Source: GDPR Source reference: https://eur-lex.europa.eu/eli/reg/2016/679/oj Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/DataOwnerBusinessRole LOST view: Organisational view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:DataOwnerBusinessRole Synonym: Data Holder (DGA), Data Creator (SiMPL) Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): In the GDPR, "controller", or "processor" on behalf of the "controller" are examples of the data owner role defined for this ABB. See GDPR https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32016R0679&from=EN , Article 4, Definitions. Interoperability Saliency: The Data Owner ABB is salient for organisational interoperability because it is responsible for the management of the data generated or consumed by the public service. The identification of Data Owners, as stated in the GDPR, is important for accountability since it identifies a person/team responsible to control the compliance of data, and for the definition of policies and standards for the alignment of public service data to GDPR. Additional information: Data owners may not work with their data every day, but are responsible for overseeing and protecting a data domain. In the context of the GDPR, data owners are accountable for the quality, integrity, and protection of their data space. In SiMPL (https://digital-strategy.ec.europa.eu/en/news/simpl-cloud-edge-federations-and-data-spaces-made-simple), the data owner is the legal entity that has sovereignty over the data, usually the creator of the data or the one who executes control over the data. See SiMPL requirements and architecture vision document. The Data Governance Act does not define the concept Data Owner, but intrinsically this role can be assigned also to the Data Holder, since "holding" usually entails "controlling". Interoperability Dimension: Governance IoP Viewpoint: Interoperability Privacy viewpoint Additional identifier: http://data.europa.eu/dr8/DataOwnerBusinessRole EIF Layer: Organisational Definition: Digital Public Service Consumer ABB is a Business Role representing the entities able to access and consume public services provided by a public authority. Source: Inspired on the information available in Digital Public Services in the Digital Economy and Society Index Source reference: https://digital-strategy.ec.europa.eu/en/policies/desi-digital-public-services Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/DigitalPublicServiceConsumerBusinessRole LOST view: Organisational view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:DigitalPublicServiceConsumerBusinessRole Example: The following implementation is an example of how this specific Architecture Building Blocks (ABB) can be instantiated as a Solution Building Block (SBB): UK Local Goverment- Transforming public services, using technology and digital tools and approaches- Case Studies (https://www.local.gov.uk/our-support/efficiency-and-productivity/transforming-public-services-using-technology-and-digital) or UNDP- COVID 19 Open Source Digital Toolkit (https://www.undp.org/sgtechcentre/digital-tools-covid-19) Interoperability Saliency: The Digital Public Service Consumer ABB is salient for organizational, semantic and technical interoperability due to it (i) provides digital business rules to consume data; (ii) enables a common understanding of the data to be exchanged with the public authority; and (iii) establish the needed mechanism to consume the information automatically. Interoperability Dimension: Structural IoP Viewpoint: Interoperability Privacy viewpoint Additional identifier: http://data.europa.eu/dr8/DigitalPublicServiceConsumerBusinessRole EIF Layer: Organisational Definition: Digital Public Service ABB is a Business Service that enables the implementation of a Public Administration digital business capability, provisioned via a digital service delivery mode by, or on behalf of a public administration. A Digital Public Service comprises any digital public service exposed to a cross-border dimension in the European Union. Source: EIF, ISA2 Core Vocabularies, IMM Source reference: [http://eur-lex.europa.eu/resource.html?uri=cellar:2c2f2554-0faf-11e7-8a35-01aa75ed71a1.0017.02/DOC_3&format=PDF][https://ec.europa.eu/isa2/actions/assessing-progress-being-made-towards-interoperability_en] [https://joinup.ec.europa.eu/catalogue/distribution/cpsv-ap-specification-v20-pdf] Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/DigitalPublicServiceBusinessService LOST view: Organisational view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:DigitalPublicServiceBusinessService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): EUROPASS2 - Make better use of skills and opportunities across Europe. Europass is a service to help individuals to communicate their skills, qualifications and experience through the use of standardised documents templates. (http://ec.europa.eu/social/main.jsp? Interoperability Saliency: The Digital Public Service ABB is salient for the organizational, semantic and technical interoperability because it represents the materialization of the service delivery in terms of (i) a common mechanism to give a response to a specific public administration procedure, (ii) data harmonization to facilitate the comprehension of the information, (iii) specific mechanisms to consume, share and reuse the information. Interoperability Dimension: Structural IoP Viewpoint: Interoperability Privacy viewpoint Additional identifier: http://data.europa.eu/dr8/DigitalPublicServiceBusinessService EIF Layer: Organisational Definition: Semantic interoperability agreement ABB is a Contract formalizing governance rules enabling collaboration between digital public services with ontological value. Source: Joinup Source reference: https://joinup.ec.europa.eu/sites/default/files/document/2015-03/Process Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/SemanticInteroperabilityAgreementContract LOST view: Semantic view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:SemanticInteroperabilityAgreementContract Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): e-Invoicing Semantic Data Model - The semantic data model includes only the essential information elements that an electronic invoice needs to ensure legal (including fiscal) compliance and to enable interoperability for cross-border, cross-sector and for domestic trade. The semantic data model may be used by public and private sector organisations for public procurement invoicing and took into account the physical and financial supply chain perspective, reflecting both private and public sector requirements, with a view to allowing the full straight-through processing of an electronic invoice. https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/2017/06/28/CEN+Publishes+eInvoicing+Semantic+Data+Model Interoperability Saliency: The Semantic Interoperability Agreement ABB is a key interoperability enabler (*) for governance interoperability by enabling the understanding of information and collaboration between digital public services. Interoperability Dimension: Governance IoP Viewpoint: Key Interoperability Enablers viewpoint Additional identifier: http://data.europa.eu/dr8/SemanticInteroperabilityAgreementContract EIF Layer: Semantic Definition: Agreement of the Use on Common Infrastructure ABB is a Contract between multiple parties that outlines the terms and conditions for sharing and utilizing a specific infrastructure or facility. The agreement on the use of common infrastructure typically outlines the rights and responsibilities of each party, the terms and conditions for access and usage, the payment or cost-sharing arrangements, and the procedures for resolving any disputes or issues that may arise. The goal of such agreements is to promote efficient and effective utilization of shared resources and to ensure that all parties are able to benefit from the use of the infrastructure in a fair and equitable manner. Source: Inspired in the UNECE definition Source reference: https://unece.org/trade/unece-work-transport/infrastructure/agreements-use-common-infrastructure Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): With Gaia-X, representatives from business, science and politics on an international level create a proposal for the next generation of data infrastructure: an open, transparent and secure digital ecosystem, where data and services can be made available, collated and shared in an environment of trust. https://www.data-infrastructure.eu/GAIAX/Navigation/EN/Home/home.html LOST view: Organisational view Interoperability saliency: Agreement on the use of common infrastructure ABB is salient for governance, organizational and legal interoperability because it comprises the agreements, procedures and rules to elaborate the principles of reference architectures for the public sector. Identifier: http://data.europa.eu/dr8/AgreementOfTheUseOnCommonInfrastructureContract eira:ID: http://data.europa.eu/dr8/AgreementOfTheUseOnCommonInfrastructureContract ABB name: eira:AgreementOfTheUseOnCommonInfrastructureContract EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2022-20-01 Definition: Technical Interoperability Agreement ABB is a Contract formalizing the technical specifications to ensure organisations operate under different technical frameworks. Source: EIF Source reference: https://ec.europa.eu/isa2/sites/isa/files/eif_brochure_final.pdf#page=27 Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/TechnicalInteroperabilityAgreementContract LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:TechnicalInteroperabilityAgreementContract Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): ETA - The European Technical Assessment (ETA) is an alternative for construction products not covered by a harmonised standard. It is a document providing information on their performance assessment. The procedure is established in the Construction Products Regulation and offers a way for manufacturers to draw up the Declaration of Performance and affix the CE marking. It contributes to the free movement of construction products and the creation of a strong Single Market. https://ec.europa.eu/growth/sectors/construction/product-regulation/european-assessment_en Interoperability Saliency: The Technical Interoperability Agreement ABB is a key enabler (*) for governance and organizational interoperability by enabling components to ensure data sharing, access and discovery between public services. Interoperability Dimension: Governance IoP Viewpoint: Highlevel viewpoint Additional identifier: http://data.europa.eu/dr8/TechnicalInteroperabilityAgreementContract EIF Layer: Technical Definition: Agreement on Privacy ABB is a Contract that enables a set of rules for the personal data of individuals' collection, processing and transference by public administrations. Source: Inspired in Data Protection Law and General Data Protection Regulation by European Comission Source reference: https://commission.europa.eu/law/law-topic/data-protection/data-protection-eu_en Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): EU-U.S. Data Privacy Framework. https://ec.europa.eu/commission/presscorner/detail/en/qanda_22_6045 LOST view: Organisational view Interoperability saliency: Agreement on Privacy ABB is salient for governance interoperability because it represents the specific rules established to establish the privacy and security framework. Identifier: http://data.europa.eu/dr8/AgreementOnPrivacyContract eira:ID: http://data.europa.eu/dr8/AgreementOnPrivacyContract ABB name: eira:AgreementOnPrivacyContract EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2022-20-01 Definition: Agreement on Provision of Digital Public Services ABB is a Contract formalizing governance rules and conditions for the functioning of digital public services when delivering the service. Source: Inspired in the works by ISA2, and the EIF-related works Source reference: https://ec.europa.eu/isa2/isa2_en Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Digital Services Act: Commission welcomes political agreement on rules ensuring a safe and accountable online environment https://ec.europa.eu/commission/presscorner/detail/en/ip_22_2545 IoP Dimension: Governance IoP, Behavioural IoP LOST view: Organisational view Interoperability saliency: The Agreement on Provision of Digital Public Services ABB is salient for governance and behavioural interoperability because it (i) specifies concrete and binding rules and service conditions which set out the expected obligations and functionality of a digital public service that has to provide content to other consumer services, and (ii) defines the digital business capabilities and functionality expected by those services that will consume the content. Identifier: http://data.europa.eu/dr8/AgreementOnProvisionOfDigitalPublicServicesContract eira:ID: http://data.europa.eu/dr8/AgreementOnProvisionOfDigitalPublicServicesContract ABB name: eira:AgreementOnProvisionOfDigitalPublicServicesContract EIRA concept: eira:ArchitectureBuildingBlock Last modification: 21/04/2021 Definition: Legal Interoperability Agreement ABB is a Contract formalizing governance rules enabling collaboration between digital public services. Source: EIF Source reference: https://ec.europa.eu/isa2/sites/isa/files/eif_brochure_final.pdf#page=27 Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/LegalInteroperabilityAgreementContract LOST view: Legal view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:LegalInteroperabilityAgreementContract Example: RDA-CODATA - Agreement that provides the guidelines and principles on the legal interoperability of research data. (http://www.codata.org/uploads/Legal%20Interoperability%20Principles%20and%20Implementation%20Guidelines_Final2.pdf) Interoperability Saliency: The Legal Interoperability Agreement ABB is a key interoperability enabler (*) for governance, organizational and legal interoperability by (i) foundations and requirements that enable the seamless exchange of data, information, and knowledge; and (ii) agreement on digital business capabilities that can map locally aligned processes between public administrations. Additional information: The legal Interoperability Agreement ABB is a specialisation of the Legal Agreement. It aims to coordinate or harmonize efficient exchange models between digital public services within a Public Administration and/or cross Public Administrations. Interoperability Dimension: Governance IoP Viewpoint: Interoperability Security viewpoint Additional identifier: http://data.europa.eu/dr8/LegalInteroperabilityAgreementContract EIF Layer: Legal Definition: Semantic Agreement ABB is a Contract formalising an agreement from a peer to the common ontology that is the result of a matching or mapping process that is used to resolve their semantic discrepancies. The combination matching process consists of a linguistic base, internal and external structure comparison. The result of the matching combination will be used to develop an agreement unit as a component of the agreement. There are some assumptions for the agreement, such as using the same language to represent the schema/ontology, labels and the meaning of a concept, and there is no individual at the common ontology. Source: Joinup Source reference: https://joinup.ec.europa.eu/taxonomy/term/http_e_f_fdata_ceuropa_ceu_fdr8_fSemanticAgreement Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/SemanticAgreementContract LOST view: Semantic view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:SemanticAgreementContract Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): SEMIC - "Supporting alignments and agreements on common definitions and specifications at the semantic layer for the Member States and the EU institutions". https://joinup.ec.europa.eu/collection/semantic-interoperability-community-semic/about Interoperability Saliency: The Semantic Agreement ABB is a key interoperability enabler because it supports semantic governance by enabling collaboration between digital public services. Additional information: The combination matching process consists of linguistic base, internal and external structure comparison. Result of matching combination will be used to develop agreement unit as component of agreement. There are some assumptions for the agreement, such as using same language to representation of schema/ontology, labels represent the meaning of concept, and there is no individual at the common ontology. Interoperability Dimension: Governance IoP Viewpoint: Highlevel viewpoint Additional identifier: http://data.europa.eu/dr8/SemanticAgreementContract EIF Layer: Semantic Definition: Agreement on Interoperability Security ABB is a Contract formalizing governance rules and conditions to grant the identification, authorization, and transmission of the data, information and knowledge being exchanged between digital public services. Source: Inspired in the works by ISA2, and the EIF-related works Source reference: https://ec.europa.eu/isa2/isa2_en Additional information: The interoperability security pays special attention to the integrity of the data, the non-repudiation, and the verification of absence of malware or other malicious content in the exchanged information. Agreements on Interoperability Security are usually aggregated to more general security frameworks covering the security of the life cycle of the data, including the the secured disposition of the data and information (i.e., transfer or secured deletetion; cfr. MoReq retention policy and plan), etc. Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): New EU Cybersecurity Strategy and new rules to make physical and digital critical entities more resilient. https://ec.europa.eu/commission/presscorner/detail/en/IP_20_2391 IoP Dimension: Governance IoP, Behavioural IoP LOST view: Organisational view Interoperability saliency: The Agreement on Interoperability Security ABB is salient for governance and behavioural interoperability because it (i) sets the conditions under which the collaboration between digital public services must take place in a secure and controlled way, and (ii) can define the security-related business capabilities of the digital public services that exchange data, information and knowledge. Identifier: http://data.europa.eu/dr8/AgreementOnInteroperabilitySecurityContract eira:ID: http://data.europa.eu/dr8/AgreementOnInteroperabilitySecurityContract ABB name: eira:AgreementOnInteroperabilitySecurityContract EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2022-20-01 Definition: Service Level Agreement ABB is a Contract formalising the agreement between a service provider and a customer or client that outlines the level of service that will be provided, as well as the metrics that will be used to measure the quality of the service Source: EIF Source reference: https://ec.europa.eu/isa2/sites/isa/files/eif_brochure_final.pdf#page=27 Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/ServiceLevelAgreementContract LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:ServiceLevelAgreementContract Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): ETA - The European Technical Assessment (ETA) is an alternative for construction products not covered by a harmonised standard. It is a document providing information on their performance assessment. The procedure is established in the Construction Products Regulation and offers a way for manufacturers to draw up the Declaration of Performance and affix the CE marking. It contributes to the free movement of construction products and the creation of a strong Single Market. https://ec.europa.eu/growth/sectors/construction/product-regulation/european-assessment_en Interoperability Saliency: The Service Level Agreement ABB is a key interoperability enabler that introduces the agreed terms and conditions for the delivery a services. The SLA is relevant and enables interoperability because include the conditions that will determine and guide the delivery and therefore, the aspects regarding interoperability with regard of services, data and infrastructures. Interoperability Dimension: Governance IoP Additional identifier: http://data.europa.eu/dr8/ServiceLevelAgreementContract EIF Layer: Technical Definition: Organisational Agreement ABB is a Contract enabling any agreement to which the Organisation or any Restricted Subsidiary is a party pursuant. Source: Inspired in the Law Insider dictionary definition Source reference: https://www.lawinsider.com/dictionary/organizational-agreement Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/OrganisationalAgreementContract LOST view: Organisational view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:OrganisationalAgreementContract Synonym: Governance Agreement Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): DSI Organisational Agreement: The Trust and Golden agreement hereby consent to this assignment by SAC of its rights under the Organizational Agreement to DSI and the assumption by DSI of SAC's interest in such Agreement and the duties and obligations thereunder, and agree, subject to the terms and conditions of said Agreement, to look to DSI for the performance of the duties and obligations formerly owed by SAC under said Agreement. https://www.sec.gov/Archives/edgar/data/1618181/000119312518153039/d419625dex42.htm Interoperability Saliency: The Organisational Agreement ABB is relevant for governance and behavioural interoperability because it sets the foundations and management for (i) controlling the collaborations and data flows established between public digital services, and (ii) specifying the digital business capabilities expected from the public digital services. Additional information: For example (among other things), fees are paid to the organisation or to a delegated party in exchange for organizational, managing, consulting or similar services. Interoperability Dimension: Governance IoP Viewpoint: Interoperability Governance viewpoint Additional identifier: http://data.europa.eu/dr8/OrganisationalAgreementContract EIF Layer: Organisational Definition: Agreement on Data Sharing ABB is a Contract formalizing the information requirements, syntax bindings, protocols and semantic artefacts that must be used for the exchange of data. Source: Inspired in the works by ISA2 (e.g. SEMIC), and the EIF-related works Source reference: https://ec.europa.eu/isa2/isa2_en Additional information: Semantic and business rules as well as validation methods, artefacts and solutions are expected to be mentioned in the contract. Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): PEPPOL's data sharing agreements IoP Dimension: Governance IoP, Behavioural IoP LOST view: Organisational view Interoperability saliency: Agreements on Data Sharing are salient for governance and behavioural interoperability because (i) it sets the rules necessary for the security and quality assurance of the data to be exchanged, (ii) the agreements on data sharing indicate the business capabilities and technical resources agreed to execute the control on the security and quality of the data being that is exchanged. Identifier: http://data.europa.eu/dr8/AgreementOnDataSharingContract eira:ID: http://data.europa.eu/dr8/AgreementOnDataSharingContract ABB name: eira:AgreementOnDataSharingContract EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2022-20-01 Definition: Legal Agreement ABB is a Contract enabling collaboration between digital public services cross legal jurisdictions. Source: EIF Source reference: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex%3A12016E207 Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/LegalAgreementContract LOST view: Legal view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:LegalAgreementContract Example: An example of a treaty that does have provisions for further binding agreements is the UN Charter. By signing and ratifying the Charter, countries agreed to be legally bound by resolutions passed by UN bodies such as the General Assembly and the Security Council. Thus, UN resolutions are legally binding on UN Member States, and no signature or ratification is necessary. https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&cad=rja&uact=8&ved=2ahUKEwiA3djvvbT2AhX1SPEDHdmuCqMQFnoECAYQAQ&url=https%3A%2F%2Fwww.phe.gov%2Fs3%2Flaw%2FPages%2FInternational.aspx&usg=AOvVaw23fJMEr0G7JOPyleNl2lrd Interoperability Saliency: The Legal Agreement ABB is salient for the governance interoperability because it sets the foundations for the coordination or harmonization between different legislations. Also this ABB is salient for the legal governance in the way of establishing the required business rules facilitate data exchange between public services at lower level. Additional information: Generally speaking a Legal Agreement Contract t is of a generic not binding nature like the declarations of Tallinn and Berlin (typically involving many legal jurisdictions). Legal agreements of binding nature typically take the form of binding legal acts like the reference list of offences punishable in the European arrest warrant (2002/584/JHA: Council Framework Decision of 13 June 2002). Interoperability Dimension: Governance IoP Viewpoint: Interoperability Governance viewpoint Additional identifier: http://data.europa.eu/dr8/LegalAgreementContract EIF Layer: Legal Definition: Framework Agreement ABB is a Contract providing an arrangement between one or more entity that provide the terms governing contracts to be established for a certain period of time, in particular with regard to price and, where necessary, the quantity envisaged. Other repetitive conditions known in advance, such as the place of delivery, may be included. They are also called blanket purchase agreements and master ordering agreements. Essentially, they are intended to provide expeditious ordering of commonly used, off-the-shelf goods, purchased on the basis of lowest price. Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/FrameworkAgreementContract EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:FrameworkAgreementContract Interoperability Dimension: Governance IoP Viewpoint: Interoperability Governance viewpoint Additional identifier: http://data.europa.eu/dr8/FrameworkAgreementContract EIF Layer: Organisational Definition: Interoperability Specification ABB is a Contract with most detail possible level of granularity on an EIRA SBB, formulated as an agreed normative statement in design terms on a legal, organisational, semantic, or technical attribute of an European Public Service. It can refer to existing standards or specifications Source: ISA2 Source reference: https://joinup.ec.europa.eu/taxonomy/term/http_e_f_fdata_ceuropa_ceu_fdr8_fInteroperabilitySpecification#:~:text=DESCRIPTION%3A%20An%20Interoperability%20Specification%20is%20a%20document%20of,It%20can%20refer%20to%20existing%20standards%20or%20specifications Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/InteroperabilitySpecificationContract LOST view: Legal view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:InteroperabilitySpecificationContract Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Technical Specification for Interoperability (TSI), a technical and operational standard which must be met by each subsystem or part of subsystem in order to meet the essential requirements and ensure the interoperability of the railway system of the European Union. Directive (EU) 2016/797 defines the subsystems, either structural or functional, forming part of the railway system of the European Union. For each of those subsystems, the essential requirements need to be specified and the technical specifications determined, particularly in respect of constituents and interfaces, in order to meet those essential requirements. The essential requirements can be summarised as safety, reliability and availability, health, environmental protection, technical compatibility and accessibility. (https://eur-lex.europa.eu/legal-content/EN/TXT/?qid=1519999459620&uri=CELEX:32016L0797) Interoperability Saliency: The interoperability specification ABB is salient for legal interoperability because it establishes the normative statements for ensuring interoperability in public services. This ABB is salient for organizational interoperability by establishing the business principles to exchange data between public services. The Interoperability specification ABB is salient for semantic interoperability too in terms of identifying technical standards for the exchange of information between public services. And finally, the ABB is salient for technical interoperability due to it determines the technical requirements to implement the interoperability between public services. Interoperability Dimension: Structural IoP Viewpoint: EIRA Ontology viewpoint Additional identifier: http://data.europa.eu/dr8/InteroperabilitySpecificationContract EIF Layer: N/A Definition: Organisational Interoperability Agreement ABB is a Contract formalising governance rules enabling collaboration between digital public services with enabling seamless interoperability enablement value. Source: Inspired in the works by ISA2, and the EIF-related works Source reference: https://ec.europa.eu/isa2/isa2_en Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/OrganisationalInteroperabilityAgreementContract LOST view: Organisational view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:OrganisationalInteroperabilityAgreementContract Example: ICAO Service Level Agreement Template - A Service Level Agreement (SLA) is an example of Interoperability Agreement in which parties agree on the description of the services to be provided by one or several parties to the other one(s). The SLA tackles topics like: service description, optional services, exclusions, limitations, service levels, service credits, escalation procedure, reporting and points of contact. (https://www.icao.int/ESAF/Documents/APIRG/APIRG18/Docs/wp17_appendices_en.pdf) Interoperability Saliency: The Organisational Interoperability Agreement ABB is a key interoperability enabler (*) for governance and behavioural interoperability by (i) binding documents which set out the precise obligations of two parties cooperating across an ‘interface’ to achieve interoperability; (ii) enabling the collaborations and data flows established between the public digital services, and (iii) enabling digital business capabilities expected from the public digital services. Additional information: (*)DECISION (EU) 2015/2240 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 25 November 2015 establishing a programme on interoperability solutions and common frameworks for European public administrations, businesses and citizens (ISA2 programme) as a means for modernising the public sector. The agreement should include purposes and goals, terms and conditions, governance, and the description of the channel(s). The EIRA© differentiates the following Interoperability Agreements: • Interoperability Service Agreement (between Public Service Consumers and Public Service Providers; • Interoperability Collaboration Agreement (between Organisations); or • Interoperability Provider Agreement (between Public Service Providers). Interoperability Dimension: Governance IoP Viewpoint: Key Interoperability Enablers viewpoint Additional identifier: http://data.europa.eu/dr8/OrganisationalInteroperabilityAgreementContract EIF Layer: Organisational Definition: Technical Agreement ABB is a Contract formalising a framework and a privileged forum to identify common interests, priorities, policy dialogue, and the necessary tools for Strategic & Technological collaboration. Source: EUR-LEX Source reference: https://eur-lex.europa.eu/collection/eu-law/inter-agree.html Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/TechnicalAgreementContract LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:TechnicalAgreementContract Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): WTO Data Exchange technical agrement: The agreement regulates the echange of data between systems and applications. https://olc.worldbank.org/sites/default/files/PMT-4.pdf Interoperability Saliency: The Technical Agreement ABB is a key interoperability enabler because it supports technical governance interoperability by enabling collaboration between digital public services. Interoperability Dimension: Governance IoP Viewpoint: Highlevel viewpoint Additional identifier: http://data.europa.eu/dr8/TechnicalAgreementContract EIF Layer: Technical Definition: National Legal Interoperability Agreement ABB is a Contract formalizing governance rules enabling collaboration amongst different levels of administrations in a State. Source: Based on the definition in the EIF about Legal Interoperability Agreement, the National Interoperability Framework Observatory (see Joinup NIFO) and existing national legal interoperability agreements. Source reference: https://ec.europa.eu/isa2/sites/isa/files/eif_brochure_final.pdf#page=27 Additional information: The National Legal Interoperability Agreement ABB is a specialisation of the Legal Interoperability Agreement. It is considered a Shared Legal Content because it enables interoperability between different digital public services of one or multiple Public Administrations within a State. Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Agreement to pass the policy of e-Signture and Certificates for the interoperability between the digital public services of the Spanish Central Administration (https://www.boe.es/diario_boe/txt.php?id=BOE-A-2012-15066) IoP Dimension: Governance IoP, Behavioural IoP LOST view: Legal view Interoperability saliency: The European Legal Interoperability Agreement ABB is salient for the governance of interoperability because it lays the European framework between public administration to enable the interoperability between public services. The European Legal Interoperability Agreement ABB is also salient for the legal interoperability due to the legal foundations and requirements that enable the seamless exchange of data, information, and knowledge between European and EEA Member State digital public services. The European Legal Interoperability Agreement ABB is also salient for the organizational interoperability since, as a consequence of the agreement, digital business capabilities can be mapped and subsequently, the process can be aligned between the Member State and EEA Public Administrations and digital public services. Identifier: http://data.europa.eu/dr8/NationalLegalInteroperabilityAgreementContract eira:ID: https://joinup.ec.europa.eu/data/dr8/NationalLegalInteroperabilityAgreement ABB name: eira:NationalLegalInteroperabilityAgreementContract EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2022-18-01 Definition: European Legal Interoperability Agreement ABB is a Contract formalizing governance rules enabling collaboration amongst the EU and EEA Member States digital public services. Source: Based on the definition in the EIF about Legal Interoperability Agreement and existing European legal interoperability agreements Source reference: https://ec.europa.eu/isa2/sites/isa/files/eif_brochure_final.pdf#page=27 Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/EuropeanLegalInteroperabilityAgreementContract LOST view: Legal view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:EuropeanLegalInteroperabilityAgreementContract Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): ELI, standing for European Legislation Identifier, is based on a voluntary agreement between EU countries, and aims to facilitate access, sharing and interconnection of legal information published in national, European and global systems. This facilitates their availability as open datasets, fostering their re-use. Interoperability Saliency: The European Legal Interoperability Agreement ABB is salient for the governance of interoperability because it lays the European framework between public administration to enable the interoperability between public services. The European Legal Interoperability Agreement ABB is also salient for the legal interoperability due to the legal foundations and requirements that enable the seamless exchange of data, information, and knowledge between European and EEA Member State digital public services. The European Legal Interoperability Agreement ABB is also salient for the organizational interoperability since, as a consequence of the agreement, digital business capabilities can be mapped and subsequently, the process can be aligned between the Member State and EEA Public Administrations and digital public services. Additional information: The European Legal Interoperability Agreement ABB is a specialisation of the Legal Interoperability Agreement ABB. It is considered a Shared Legal Content because it enables interoperability between different EU MS and stakeholders. Interoperability Dimension: Governance IoP Additional identifier: http://data.europa.eu/dr8/EuropeanLegalInteroperabilityAgreementContract EIF Layer: Legal Definition: Data Representation ABB is a Representation refers to the method or mechanism in which data is encoded and stored in a computer system. It involves transforming data from its original form into a format that can be processed and manipulated by a computer Source: Inspired in ArchiMate® definition Source reference: https://pubs.opengroup.org/architecture/archimate3-doc/chap08.html#_Toc10045383 Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/DataRepresentationRepresentation LOST view: Semantic view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:DataRepresentationRepresentation Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): ESPD data - XML representation: European Single Procurement Document (ESPD) is a self-declaration of the businesses' financial status, abilities and suitability for a public procurement procedure. It is available in all EU languages and used as a preliminary evidence of fulfilment of the conditions required in public procurement procedures across the EU. Thanks to the ESPD, the tenderers no longer have to provide full documentary evidence and different forms previously used in the EU procurement, which means a significant simplification of access to cross-border tendering opportunities. [...] The online form can be filled in, printed and then sent to the buyer together with the rest of the bid. (https://ec.europa.eu/tools/espd/filter?lang=en) Interoperability Saliency: The Data Representation ABB is a key interoperability enabler because it ensures a common and unambiguous interpretation of Data (*). Additional information: (*)DECISION (EU) 2015/2240 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 25 November 2015 establishing a programme on interoperability solutions and common frameworks for European public administrations, businesses and citizens (ISA2 programme) as a means for modernising the public sector. Interoperability Dimension: Structural IoP Viewpoint: Highlevel viewpoint Additional identifier: http://data.europa.eu/dr8/DataRepresentationRepresentation EIF Layer: Semantic Definition: Linked Open Data ABB is a Representation that enables the procedures of publishing structured data enriched with metadata to ensure data understanding, connection, findability and link with informational resources. Source: EUROPEANA PRO Source reference: https://pro.europeana.eu/page/linked-open-data Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/LinkedOpenDataRepresentation LOST view: Semantic view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:LinkedOpenDataRepresentation Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): EuropeanaPro https://pro.europeana.eu/page/linked-open-data Interoperability Saliency: The Linked Open Data Representation ABB is salient for semantic interoperability because it provides a set of publishing, sharing, and connection methods that allow linking and publishing the data from digital public services, making it more meaningful and increasing the quality and scope of data and services. Moreover, it increases data discoverability and maximises the reuse and exchange of data. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/LinkedOpenDataRepresentation EIF Layer: Semantic Definition: Linked data ABB is a Representation that enables a set of principles and technologies for publishing, sharing, and connecting structured data on the web. Source: W3C-Linked Data Source reference: https://www.w3.org/standards/semanticweb/data Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/LinkedDataRepresentation LOST view: Semantic view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:LinkedDataRepresentation Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Publications Office Linked Data Repository. https://op.europa.eu/en/linked-data Interoperability Saliency: The Linked Data Representation ABB is salient for semantic interoperability because it provides a set of publishing, sharing, and connection methods that allow linking the data from digital public services, making it more meaningful and increasing the quality and scope of data and services. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/LinkedDataRepresentation EIF Layer: Semantic Definition: Legal Act Representation ABB is a Representation manifesting the content of a legal Act in a digital format, thus making possible digital public services to exchange such content. Source: Based on the IFLA concepts of 'manifestation' and Legal Act. Source reference: https://repository.ifla.org/handle/123456789/40 Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/LegalActRepresentationRepresentation LOST view: Legal view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:LegalActRepresentationRepresentation Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): The XML specification Akoma Ntoso is used to address the need of the public administration and European Institutions to generate draft legislation in the legal XML format Akoma Ntoso (the OASIS TC LegalXMLDocument). This specification is used by LEOS (Legislation Editing Open Software, https://joinup.ec.europa.eu/collection/justice-law-and-security/solution/leos-open-source-software-editing-legislation/release/330). Interoperability Saliency: The Legal Act Representation ABB is salient for the Behavioural Interoperability because it enables the exchange, reading and processing of Legal Acts. It is also salient for the Structural Interoperability since the content digitally represented can be searched and reused in different domains and for differnt purposes. Additional information: Legal Act Representation can be human or machine readable. In the context of digital public services they are, either way, digitally supported (i.e., no physical sypports like paper or other that are not bytes are involved in the exchange of data and information). Interoperability Dimension: Structural IoP Viewpoint: Highlevel viewpoint Additional identifier: http://data.europa.eu/dr8/LegalActRepresentationRepresentation EIF Layer: Legal Definition: Knowledge ABB is a Representation that refers to a perceptible form of stored information in a human/artificial memory representing the understanding and awareness that a person has about a particular subject, topic, or area of study. Knowledge is generally context related. Source: FREE DICTIONARY Source reference: https://encyclopedia2.thefreedictionary.com/knowledge Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/KnowledgeRepresentation LOST view: Semantic view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:KnowledgeRepresentation Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Core Vocabularies for public administration. https://joinup.ec.europa.eu/collection/semic-support-centre/core-vocabularies Interoperability Dimension: Structural IoP Viewpoint: Highlevel viewpoint Additional identifier: http://data.europa.eu/dr8/KnowledgeRepresentation EIF Layer: Semantic Definition: Linked Data Event Stream ABB is a Representation of immutable objects that can be publish, consumed and processing in real-time according to the Linked Data principles. Source: SEMIC Source reference: https://joinup.ec.europa.eu/collection/semic-support-centre Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/LinkedDataEventStreamRepresentation LOST view: Semantic view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:LinkedDataEventStreamRepresentation Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): LDES - SEMIC Linked Event Streams pilot for the ERA (European Railway Agency). LDES provides a data publishing alternative based on Linked Data principles, that models dataset changes as a stream of events. This enables opportune data synchronization tasks and access to previous versions of dataset (historic data). In this pilot we aim to establish the foundations and show the benefits of the LDES approach, to power a specific use case required by ERA, namely the infrastructure change alert. https://joinup.ec.europa.eu/collection/semantic-interoperability-community-semic/event/semic-linked-data-event-streams-pilot-era-9th-june Interoperability Saliency: The Linked Data Event Stream Representation ABB is salient for semantic interoperability because it contributes to secure data consumption and processing ensuring that exchanged data is not modified or altered. The fact of being immutable is relevant to ensure data integrity over time. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/LinkedDataEventStreamRepresentation EIF Layer: Semantic Definition: Open Data ABB is a Representation of the information collected, produced or paid for by the public bodies and made freely available for re-use for any purpose Source: European Comission Source reference: https://data.europa.eu/en/trening/what-open-data Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/OpenDataRepresentation LOST view: Semantic view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:OpenDataRepresentation Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): datos.gob.es https://datos.gob.es/en Interoperability Saliency: The Open Data Representation ABB is salient for semantic interoperability because it is the basis for sharing, reusing and making available relevant and public information from public organisations and the digital public services delivery. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/OpenDataRepresentation EIF Layer: Semantic DEFINITION: Service Discovery Component ABB is an Application Component locating a machine-processable description of a service-related resource that may have been previously unknown and that meets certain functional criteria. It involves matching a set of functional and other criteria with a set of resource descriptions. The goal is to find an appropriate service-related resource. Source: W3C (https://www.w3.org/TR/2004/NOTE-ws-gloss-20040211/) INTEROPERABILITY SALIENCY: IoP Dimension: Structural IoP The Service Discovery Component ABB  is salient for technical interoperability because it allows to implement the funcionality of sharing services available for reuse as stated in the EIF recommendation n°36: "Develop a shared infrastructure of reusable services and information sources that can be used by all public administrations". EXAMPLES: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Consul Consul has multiple components, but as a whole, it is a tool for discovering and configuring services in an infrastructure. It provides several key features: • Service Discovery: Clients of Consul can provide a service, such as api or mysql, and other clients can use Consul to discover providers of a given service. Using either DNS or HTTP, applications can easily find the services they depend upon. • Health Checking: Consul clients can provide any number of health checks, either associated with a given service ("is the webserver returning 200 OK"), or with the local node ("is memory utilization below 90%"). This information can be used by an operator to monitor cluster health, and it is used by the service discovery components to route traffic away from unhealthy hosts. • KV Store: Applications can make use of Consul's hierarchical key/value store for any number of purposes, including dynamic configuration, feature flagging, coordination, leader election, and more. The simple HTTP API makes it easy to use. • Multi Datacenter: Consul supports multiple datacenters out of the box. This means users of Consul do not have to worry about building additional layers of abstraction to grow to multiple regions. Source: (https://www.consul.io/) Implements the functionalities of i) administration of services and/or systems and ii) monitoring of services and/or systems and iii) the various functions that manages the full lifecycle of solutions, with the goal of ensuring that these services and/or systems run in an efficient and effective way. Source: ISA2 – EIA Action The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): AnywhereTS AnywhereTS is an open source configuration tool to create and deploy thin-clients, utilizing ordinary office PCs as clients. The organization can re-use already existing office PCs instead of, or in addition to using dedicated thin clients. https://sourceforge.net/projects/anywherets/ A Business Process Management Component encapsulates the functionalities for the orchestration/choreography of business processes. DESCRIPTION: Implements the functionality of documenting the configuration and architecture of solutions. Source: ISA2 - EIA Action INTEROPERABILITY SALIENCY: The Configuration and Solution of Cartography Component ABB  is salient for technical interoperability because it provides the implementation of the functionalities which can be exploited to document the interoperabilty features of a solution or a set of solution/services. EXAMPLES: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Essential The EA Essential tool provides with a semantically-rich meta-model. This means accurate modelling which allows for sophisticated reporting. Essential can be configured to import data from a wide range of sources such as CMDBs, Business Process Modelling tools, PMO tools, etc. The Essential Import Utility REST API allows to schedule automated imports from external data sources to keep the repository accurate and current. Complex queries can be built on the repository using the query wizard in Essential Open Source. In addition to traditional the Enterprise Architecture assets, Essential also manages information about the entire organization including resources, skills, contracts, risk, security and more. https://www.enterprise-architecture.org/features.php Implements the functionalities that include i) the applications, ii) infrastructure and tools, and/or iii) best practices that enable access to and analysis of information to improve and optimize decisions and performance. Based on Gartner http://www.gartner.com/it-glossary/business-intelligence-bi/ The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): JasperReports The JasperReports Library is an open source reporting engine. It is entirely written in Java and it is able to use data coming from any kind of data source and produce pixel-perfect documents that can be viewed, printed or exported in a variety of document formats including HTML, PDF, Excel, OpenOffice and Word. https://community.jaspersoft.com/project/jasperreports-library Implements the functionalities responsible for the efficient and systematic control of the i) creation, ii) receipt, iii) maintenance, iv) use and v) disposal of records, including processes for capturing and maintaining evidence of, and information about, business activities and transactions in the form of records. ISO 15489-1:2001 defines records as "information created, received, and maintained as evidence and information by an organization or person, in pursuance of legal obligations or in the transaction of business". Based on ISO 15489-1:2016 https://www.iso.org/standard/62542.html The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): OpenKM OpenKM is an Enterprise Document and Record Management System that has support for records management software. The file plan of OpenKM records management software specifies how records are to be organized once they have been created or received, provides a roadmap to the records created and maintained by an organizational unit, and facilitates dispositioning of the records. The file plan is created by detailing the file series of the records in your organizational unit, as well as information about how they are managed and by whom. Features: • File plan o The file plan of OpenKM document management describes every type of records in the organization, the location where they should be stored, the rules applying to them, the retention schedule and timeline, manner of their disposition, and the person(s) responsible for their management. • Inheritance o OpenKM allows inheritance between file series. • Security o Set security by file series of the record. • Record manager: o Create your own dynamic logic for each file series, for example, based on metadata values, the file series can be promoted as "record" status. • Search: o Define common searches based on file series of record. • Classification of business activities: o Classification system reflect the business of the organization from which they derive and are normally based on an analysis of the organization's business activities. The system can be used to support a variety of records management processes. • Catalogue: o Create dynamic destinations based on record values. o Dynamic wizard requiring the user for metadata values based on file series of the record (control of the creation). • Disposition: o Set retention schedule and period. o Create dynamic disposition based on record values. https://www.openkm.com/ ePHOENIX epoline® PHOENIX (ePHOENIX) is a document and dossier management system designed to support the processes involved in the handling of Intellectual Property (IP)-related documents. The system, which was developed by the European Patent Office, allows IP offices to manage application dossiers in electronic form. It provides a means for scanning all incoming documents and a user interface to display the resulting electronic dossier on screen, as well as supporting the printing and distribution of work. ePHOENIX replaces physical paper files, thus removing the need for space-consuming archives and time-consuming transportation and management. Representing a further step towards the paperless office, the system improves efficiency and cost-effectiveness throughout the life-cycle of IP documents. ePHOENIX is highly configurable. It provides tools and interfaces which allow existing IT systems, organisational structures, working procedures and conventions to be retained. This means minimal development costs, minimal risk and maximum user acceptance. Furthermore, it is a flexible Java-based system that can operate in a wide variety of IT architectures. Thanks to its customisation possibilities, ePHOENIX can also be used to handle non-IP documents. http://ephx.sourceforge.net/summary.html Implements the functionalities of i) managing service consumption (i.e. consumers) and ii) controlling service consumption by partners (i.e. consumers) in order to ensure scalability and availability. It enables the management of IES' interoperability agreements Source: ISA2 – EIA Action The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): OpenNebula The OpenNebula monitoring subsystem gathers information relative to the hosts and the virtual machines, such as the host status, basic performance indicators, as well as VM status and capacity consumption. This information is collected by executing a set of static probes provided by OpenNebula. The information is sent according to the following process: each host periodically sends monitoring data to the front-end which collects it and processes it in a dedicated module. This model is highly scalable and its limit (in terms of number of VMs monitored per second) is bounded to the performance of the server running on and the database server. OpenNebula also brings resource quota management to allocate, track and limit resource utilization/consumption. https://opennebula.org/ Implements the functionalities of i) transmission of text and/or ii) broadcasting of “audio and video” content. Source: ISA2 - EIA Action Syn. Social Network The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Kune Kune is a free and open source federated collaborative social network, focused on collaboration rather than just on communication. That is, it provides online real-time collaborative editing (based on Apache Wave), decentralized social networking and web publishing, while focusing on workgroups rather than individuals. It aims to allow the creation of online spaces for collaborative work, where organizations and individuals can build projects online, coordinate common agendas, set up virtual meetings, publish on the web, and join organizations with similar interests. Kune is 100% free software (AGPLv3), built with free tools. https://github.com/comunes/kune DESCRIPTION: It is an interoperable european solution, developed by, or in behalf of, an European public administration that enables the delivery of a digital public service, all of it, in fulfilment of a shared European legislation framework, being managed according a shared governance framework, accessing semantic assets in a shared knowledge base and using digital resources of a shared platform enabling cross-border/cross-organization exchange of data, information, and knowledge indistinctly between public administrations, businesses and citizens in support to the implementation and advancement of an EU, national or local public policy. Based on ISA TES definition https://joinup.ec.europa.eu/node/149889 IoP Dimension: Structural IoP, Behavioral IoP EXAMPLES: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): eDelivery Supporting secure and reliable exchange of data and documents eDelivery is a network of nodes for digital communications. It is based on a distributed model where every participant becomes a node using standard transport protocols and security policies. eDelivery helps public administrations to exchange electronic data and documents with other public administrations, businesses and citizens, in an interoperable, secure, reliable and trusted way. eDelivery is one of the building blocks of the European Commission's Connecting Europe Facility (CEF). These building blocks are reusable specifications, software and services that will form part of a wide variety of IT systems in different policy domains of the EU. The CEF eDelivery building block is based on the AS4 messaging protocol, open and free for all, developed by the OASIS standards development organisation. To ease its adoption in Europe, eDelivery uses the AS4 implementation guidelines defined by the Member States in the e-SENS Large Scale Pilot. Organisations must install an Access Point, or use a Service Provider, to exchange information with the AS4 messaging protocol. https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/eDelivery DESCRIPTION: Interoperable European Solution Component represents the encapsulation of a functionality provided by an Interoperable European Solution. Based on ArchiMate® v3 http://pubs.opengroup.org/architecture/archimate3-doc/chap09.html INTEROPERABILITY SALIENCY: IoP Dimension: Structural IoP The Interoperable European Solution Component ABB is salient for technical interoperability because it is a central element the EIF's conceptual model for integrated public services. it represents all the functionalities provided by an Interoperable European Solutionas as stated in the EIF: "Technical interoperability the applications and infrastructures linking systems and services." EXAMPLES: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): EU Login EU Login is the European Commission's user authentication service. It allows authorised users to access a wide range of Commission web services and websites, using a single email address and password. EU Login implements the single sign-on functionality. https://webgate.ec.europa.eu/cas/help.html Implements the functionality of the categorisation of information resources so that they can be stored, published and reused in multiple contexts. Based on DAMA http://www.dama.org/ The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Plone Plone provides the following features: - Enterprise integration: Plone connects with specialized applications and standard enterprise systems like CRMs, Salesforce, and Oracle. It integrates with web servers, SQL and NoSQL databases, continuous integration tools, web services, and frameworks. - Flexible Workflows: Manage the life cycle of your content (from initial creation to publication and storage) with version control, content locking, document and digital asset management, and search. - Industrial Strength Security: The creativity and speed of Open Source blended with a technologically-advanced Python backend yields superior security without sacrificing power or extensibility. The extremely low number of vulnerabilities found in Python and Plone demonstrates the maturity of Plone’s security and development processes - Extensibility: hundreds of add-ons for document and content storage, content delivery, forms processing, social syndication, personalization and more - Scalability: Plone also has outstanding clustering capabilities - allowing websites to be split across multiple servers to handle high traffic - Search Capabilities: Live search gets inside Word documents and PDF files. Supercharge search with add-ons for Google Search Appliance, Elasticsearch and Apache Solr. - Intranets and Multi-site Management - Theming engine and Multilingual - WCAG 2.0 compliant and meets or exceeds W3C’s WAI-AA https://plone.com/features DEFINITION: Digital Service Infrastructure ABB is an Application Component enabling networked services to be delivered electronically, typically over the internet, providing trans-European interoperable services of common interest for citizens, businesses and/or public authorities, and which are composed of core service platforms and generic services Source: Regulation (EU) No 283/2014 (http://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32014R0283&from=EN) INTEROPERABILITY SALIENCY: IoP Dimension: Structural IoP, Behavioral IoP The Digital Infrastructure Service ABB  is salient for technical interoperability because it a central element through which interoperability is ensured and by definition, as intended in the EIRA, Digital Service Infrastructure provide trans-European interoperable services. EXAMPLES: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): CEF Digital Service Infrastructure for eHealth eHealth refers to tools and services using information and communication technologies (ICTs) that can improve prevention, diagnosis, treatment, monitoring and management. So far the Digital Service Infrastructure for eHealth is planned to support several services: - Cross-border patient summary service - ePrescriptions and eDispensations In the future, two other services, the European Reference Networks and Interoperable Patient registries might be deployed. Source: (https://webgate.ec.europa.eu/sanco-xmlgate/Login.jsp) Implements the functionality of tracing all events and user actions impacting a data entity throughout its lifecycle (from its creation to its disposal). It can be used to reproduce a certain state of a data entity at a certain moment in time. Logging = To record details of information or events in an organized record-keeping system, usually sequenced in the order in which they occurred. Based on ISACA https://www.isaca.org The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Log4j 2 Apache Log4j is a Java-based logging utility, part of the Apache Logging Services project of the Apache Software Foundation. Log4j 1.x has been widely adopted and used in many applications. However, through the years development on it has slowed down. It has become more difficult to maintain due to its need to be compliant with very old versions of Java and became End of Life in August 2015. Improvements in Log4j 2: • Log4j 2 is designed to be usable as an audit logging framework. • Log4j 2 contains next-generation Asynchronous Loggers based on the LMAX Disruptor library. In multi-threaded scenarios Asynchronous Loggers have 10 times higher throughput and orders of magnitude lower latency than Log4j 1.x and Logback. • Log4j 2 is garbage free for stand-alone applications, and low garbage for web applications during steady state logging. This reduces pressure on the garbage collector and can give better response time performance. • Log4j 2 uses a Plugin system that makes it extremely easy to extend the framework by adding new Appenders, Filters, Layouts, Lookups, and Pattern Converters without requiring any changes to Log4j. • Support for custom log levels. Custom log levels can be defined in code or in configuration. • Support for Message objects. Messages allow support for interesting and complex constructs to be passed through the logging system and be efficiently manipulated. • Log4j 2 takes advantage of Java 5 concurrency support and performs locking at the lowest level possible. • It is an Apache Software Foundation project following the community and support model used by all ASF projects. http://logging.apache.org/log4j/2.x/index.html DEFINITION: Data Warehouse Component ABB is an Application Component transforming raw data and storing them in query-able forms. It is an information system that contains historical and commutative data from single or multiple sources. It simplifies reporting and analysis process of the organization. Source: ISA2 - EIA Action INTEROPERABILITY SALIENCY: IoP Dimension: Structural IoP The Data Warehouse Component ABB  is salient for technical interoperability because it provides and shares the functionality for the short-term or medium-term preservation of records and information in electronic form in order to ensure their temporal egibility, reliability and integrity and to ease their management as stated in the EIF: "Legislation requires that decisions and data are stored and can be accessed for a specified time. This means that records and information in electronic form held by public administrations for the purpose of documenting procedures and decisions must be preserved and be converted, where necessary, to new media when old media become obsolete. The goal is to ensure that records and other forms of information keep their legibility, reliability and integrity and can be accessed as long as needed subject to security and privacy provisions." EXAMPLES: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): ESSnet: The overall objective of this ESSnet is to provide assistance in the development of more integrated databases and data production systems for business statistics in Member States. Therefore the ESSnet has to work on issues that are common for the majority of the ESS NSIs when applying a data warehousing approach for statistics. Its general objectives are: - Review of current best practices in integrated business data systems - Identification of problems and solutions in current practices and the opportunities that a data warehouse might provide - Examination of ways in which data can be combined to support new outputs - Provision of recommendations on how the ESS can improve data warehousing Source: (https://ec.europa.eu/eurostat/cros/content/data-warehouse-sga1_en) DESCRIPTION: Shares the functionality of documenting the configuration and architecture of solutions. Source: ISA2 - EIA Action INTEROPERABILITY SALIENCY: The Configuration and Solution of Cartography Service ABB  is salient for technical interoperability because it can be used to document the interoperabilty features of a solution or a set of solution/services. EXAMPLES: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Essential The EA Essential tool provides with a semantically-rich meta-model. This means accurate modelling which allows for sophisticated reporting. Essential can be configured to import data from a wide range of sources such as CMDBs, Business Process Modelling tools, PMO tools, etc. The Essential Import Utility REST API allows to schedule automated imports from external data sources to keep the repository accurate and current. Complex queries can be built on the repository using the query wizard in Essential Open Source. In addition to traditional the Enterprise Architecture assets, Essential also manages information about the entire organization including resources, skills, contracts, risk, security and more. https://www.enterprise-architecture.org/features.php Shares the functionality of providing detailed reports using unified views of enterprise data. This includes, but is not limited to, financial statements, financial information, non-financial information and regulatory filings such as annual and quarterly financial statements. Based on XBRL (eXtensible Business Reporting Language) Specification http://www.xbrl.org/Specification/XBRL-2.1/REC-2003-12-31/XBRL-2.1-REC-2003-12-31+corrected-errata-2013-02-20.html The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): BIRT BIRT is an open source software project that provides the BIRT technology platform to create data visualizations and reports that can be embedded into rich client and web applications, especially those based on Java and Java EE. BIRT is a top-level software project within the Eclipse Foundation, an independent not-for-profit consortium of software industry vendors and an open source community. BIRT technology platform is one of the most widely adopted data visualization and reporting technologies with over 12 million downloads and over 2.5M developers across 157 countries. BIRT also has a large, active and growing developer community representing all types of organizations. http://www.eclipse.org/birt/about/ DEFINITION: Shared platform ABB is a Application Service setting technical (re)usable resources with convergence power, in relation to public policy goals attainment, enabling interoperability from a technical perspective cross levels in a public administration, cross public administrations, and cross borders. This convergence power is based on the instrumental nature and efficiencies of these resources for enabling common problem-solving approaches. The degree of achievement could range from an ideal perfect shared platform (i.e. no interoperability barriers from the technical perspective) to an imperfect or even null shared platform (i.e. some interoperability barriers from the technical perspective). The level of technical interoperability will constrain digital public services cross levels in a public administration, cross public administrations, and cross borders. The shared platform enables: i) structural interoperability with technical resources supporting reusing and/or sharing of digital public services (i.e. service registry service); ii) behavioural interoperability with technical resources supporting exchanging capabilities of data, information or knowledge with internal/external peers (i.e. Technical interfaces); and iii) governance interoperability with technical resources supporting the assurance and control of collaboration with internal/external peers exchanging data, information, and knowledge(i.e. Technical Interoperability Agreements). Source: Gartner (https://www.gartner.com/en/information-technology/glossary/platform-digital-business) INTEROPERABILITY SALIENCY: IoP dimensions: Structural IoP Behavioral IoP, Governance IoP This ABB is a key interoperability enabler because it supports to achieve technical interoperability with public policy goals convergence value by all in all enabling i) the provision/consumption of back-office digital public services, ii) the exchange of data, information, and knowledge between digital public services and individuals , and iii) collaboration between digital public services. EXAMPLES: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): The Commission proposed a framework for a European Digital Identity which will be available to all EU citizens, residents, and businesses in the EU. Citizens will be able to prove their identity and share electronic documents from their European Digital Identity wallets with the click of a button on their phone. They will be able to access online services with their national digital identification, which will be recognised throughout Europe. Very large platforms will be required to accept the use of European Digital Identity wallets upon request of the user, for example to prove their age Source: (https://ec.europa.eu/commission/presscorner/detail/en/IP_21_2663) Shares the functionalities of emphasising the importance of coordination and control across the various Functions, Processes, and Systems necessary to manage the full Lifecycle of IT Services. The Service Management Lifecycle approach considers the Strategy, Design, Transition, Operation and Continuous Improvement of IT Services. Based on ITIL® V3 Glossary v01, 30 May 2007 https://www.axelos.com/corporate/media/files/glossaries/itil_2011_glossary_gb-v1-0.pdf The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Foreman Foreman is an open source complete lifecycle systems management tool for provisioning, configuring and monitoring of physical and virtual servers. It permits system administrators to easily automate repetitive tasks, quickly deploy applications, and proactively manage servers, on premise or in the cloud. • Provisioning: Bare metal, Amazon EC2, Google Compute Engine, OpenStack, Libvirt, oVirt, VMware, and many other providers allow to manage a hybrid cloud through Foreman. • Configuration: an external node classifier, hiera-like parameters, and reports monitoring for Puppet, Salt and Chef are included. Completely ready to tweak host groups in the data centre. • Monitor hosts: Foreman reports tells exactly what happened in your nodes, and alerts if necessary. The dashboard shows which hosts are healthy, and which ones are outdated. https://theforeman.org/ DESCRIPTION: Represents an explicitly defined shared application behavior of an Inteoperable European Solution. Based on ArchiMate® v3 http://pubs.opengroup.org/architecture/archimate3-doc/chap09.html INTEROPERABILITY SALIENCY: IoP Dimension: Behavioral IoP The Interoperable European Solution service ABB is salient for technical interoperability because it is a central element the EIF's conceptual model for integrated public services. it represents the generalisation of all application services provided by an Interoperable European Solutionas as stated in the EIF: "Technical interoperability the applications and infrastructures linking systems and services." EXAMPLES: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): EU Login EU Login is the European Commission's user authentication service. It allows authorised users to access a wide range of Commission web services and websites, using a single email address and password. EU Login implements the single sign-on functionality. https://webgate.ec.europa.eu/cas/help.html Shares the functionality of modelling a sequence of operations, states, and conditions that control the interactions involved in the participating services. The interaction prescribed by a choreography results in the completion of some useful function. A choreography can be distinguished from an orchestration. An orchestration defines the sequence and conditions in which one service invokes other services in order to realize some useful function. Based on W3C https://www.w3.org/TR/ws-arch/ The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Camunda The core of Camunda BPM is a model execution engine that supports the OMG standards BPMN 2.0 for process automation, CMMN 1.1 for case management and DMN 1.1 for decision management. Camunda BPM ships with a set of applications to help you model, execute and administer process applications running on the Camunda core engine. Those applications interact with the core engine's public REST API. You can also create your own applications that may also use the core engine's public Java API. It is lightweight and requires less than 3MB of disk space. It can run in any Java Virtual Machine (JVM) and comes with extended integration for different runtime containers. The engine can be accessed via the REST API, or via the Java API and existing integrations with Spring and Java EE can be used. BPMN service tasks can be implemented in Java code, or the built-in REST and SOAP connectors can be used. Scripts, expressions and templates can also be applied for process implementation. Clustering for horizontal scalability is straightforward as the engine is stateless: multiple instances can share the same database. BPMN 2.0 Processes permits the fully automated service orchestration and human workflow management. https://camunda.org/features/ Shares the functionalities of i) building analysis models and simulations to create scenarios, ii) understand realities and/or iii) predict future states. Business analytics includes data mining, predictive analytics, applied analytics and statistics, and is delivered as an application suitable for a business user. These analytics solutions often come with prebuilt industry content that is targeted at an industry business process (for example, claims, underwriting or a specific regulatory requirement). Based on Gartner http://www.gartner.com/it-glossary/business-analytics/ The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): KNIME® KNIME® Analytics Platform is the leading open solution for data-driven innovation, helping discovering the potential hidden in data, mine for fresh insights, or predict new futures. This enterprise-grade, open source platform is scalable. KNIME Analytics Platform provides to data scientists more than 1000 modules, hundreds of ready-to-run examples, a comprehensive range of integrated tools, and a wide choice of advanced algorithms. • Data Blending: simple text files, databases, documents, images, networks, and even Hadoop-based data can all be combined within the same visual workflow. • Tool Blending: integration of more than a dozen tools, including legacy scripting/code, allows expertise to be reused, graphically documented, and shared among data scientists. • Visual: easy-to-learn graphical interface means that coding is optional and work is visually documented. https://www.knime.com/knime-server Shares the functionality of broadcasting of “audio and video” content over the internet or satellite. Source: ISA2 - EIA Action Syn. Social Network The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Avalon Media System The Avalon Media System is an open source system for managing and providing access to large collections of digital audio and video. The freely available system enables libraries and archives to easily curate, distribute and provide online access to their collections for purposes of teaching, learning and research. The Avalon Community is made up of a dozen educational, media and open-technology institutions. http://www.avalonmediasystem.org/project DEFINITION: Service Discovery Service ABB is an Application Service locating a machine-processable description of a service-related resource that may have been previously unknown and that meets certain functional criteria. It involves matching a set of functional and other criteria with a set of resource descriptions. The goal is to find an appropriate service-related resource. Source: W3C (https://www.w3.org/TR/2004/NOTE-ws-gloss-20040211/) INTEROPERABILITY SALIENCY: IoP Dimension: Behavioral IoP The Service Discovery Service ABB is salient for technical interoperability because it allows to discover service available for reuses as stated in the EIF recommendation n°36: "Develop a shared infrastructure of reusable services and information sources that can be used by all public administrations." EXAMPLES: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): jUDDI jUDDI is an open source Java implementation of OASIS the Universal Description, Discovery, and Integration (UDDI) specification for (Web) Services. The jUDDI project includes Scout. Scout is an implementation of the JSR 93 - JavaTM API for XML Registries 1.0 (JAXR). Features: • Platform Independent • Use with any relational database that supports ANSI standard SQL (MySQL, Oracle, DB2, Sybase, Derby etc.) • Deployable on any Java application server that supports the Servlet 2.3 specification • jUDDI registry supports a clustered deployment configuration. • Easy integration with existing authentication systems • Supports InVM embeddable mode jUDDIv3 Services: • UDDI Specification version 3.0.2 compliant • UDDI Specification version 2.0.4 interoperability services (BETA) • Built on JAXB and JAX-WS standardized interfaces, tested on Apache CXF • Built on JPA standardized interfaces, tested with Apache OpenJPA and Hibernate • Pre-configured bundle deployed to Apache Tomcat • Full featured user interface (based on Bootstrap) • User, Administrative and Developer Documentation • Includes extensive predefined tModels, such as Quality of Service Metrics Source: (http://juddi.apache.org/) DEFINITION: Service Registry ABB is an Application Service providing access rights for data that is necessary for service-oriented architecture projects to target fast and easy communication and data exchange. This ABB is a key interoperability enabler (*) for sharing/PROVISIONING and reusing/CONSUMING back-office services. Source: Atlassian (https://developer.atlassian.com/server/framework/atlassian-sdk/service-registry/) INTEROPERABILITY SALIENCY: IoP Dimension: Structural IoP, Behavioral IoP The Service Registry Service is a key interoperability enabler because it provides access to software systems over the Internet using standard protocols. In the most basic scenario there is a Web Service Provider that publishes a service and a Web Service Consumer that uses this service. EXAMPLES: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): ZooKeeper ZooKeeper is a centralized service registry for maintaining configuration information, naming, providing distributed synchronization, and providing group services. All of these kinds of services are used in some form or another by distributed applications. Each time they are implemented there is a lot of work that goes into fixing the bugs and race conditions that are inevitable. Because of the difficulty of implementing these kinds of services, applications initially usually skimp on them, which make them brittle in the presence of change and difficult to manage. Even when done correctly, different implementations of these services lead to management complexity when the applications are deployed. Source: (https://zookeeper.apache.org/) Shares the functionalities of i) transmission of text and/or ii) broadcasting of “audio and video” content. Source: ISA2 - EIA Action Syn. Social Network The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): HumHub User Mail System HumHub is a free and open source social network software coded on top of the Yii PHP framework that provides an easy to use toolkit for creating and launching an own social network. The platform can be used for internal communication and collaboration that can range from a few users up to huge Intranets that serve companies with hundreds and thousands of employees. The platform was meant to be self-hosted and currently comes with pretty normal requirements, working with most shared hosting environments around. HumHub also supports themes and modules to extend the functionality for almost all requirements. The user mail system module provides a private messaging system to communicate with one or more users. https://github.com/humhub/humhub-modules-mail Shares the functionalities responsible for the efficient and systematic control of the i) creation, ii) receipt, iii) maintenance, iv) use and v) disposal of records, including processes for capturing and maintaining evidence of, and information about, business activities and transactions in the form of records. ISO 15489-1:2001 defines records as "information created, received, and maintained as evidence and information by an organization or person, in pursuance of legal obligations or in the transaction of business". Based on ISO 15489-1:2016 https://www.iso.org/standard/62542.html The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Council of Europe - Documents, Records and Archives You will find on the Documents, Records and Archives website information about the Council of Europe's documents, records and archives, how they are organised and how to access them, whatever their format (audio-visual, electronic, paper or web archives): • information about the Council of Europe's documents, records and archives, how they are organised and how to access them, whatever their format (audio-visual, electronic, paper or web archives) • information on the rules and procedures governing access • search tools and other professional tools • a timeline with a selection of themes related to the construction of the Council of Europe and the personalities involved (being developed) • an information management guidance page https://www.coe.int/en/web/documents-records-archives-information/home Barracuda Cloud Archiving Service Barracuda Cloud Archiving Service permits to protect email for On-Premises, Cloud and Hybrid Environments. It provides cloud-based archiving of email, enabling organizations to meet demanding compliance requirements and address eDiscovery requests effectively and easily. Ideal for organizations using cloud-based email services like Office 365, Barracuda stores archived email in a separate, secure repository for as long as needed without risk of corruption or deletion. With Barracuda, compliance is easy to demonstrate, and end users can have read only access to search and retrieve archived email at any time from any device. https://www.barracuda.com/products/cloudarchivingservice Shares the functionalities of i) managing service consumption by partners (i.e. consumers) and ii) controlling service consumption by partners (i.e. consumers) in order to ensure scalability and availability. It enables the management of IES' interoperability agreements Source: ISA2 – EIA Action The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): OpenNebula The OpenNebula monitoring subsystem gathers information relative to the hosts and the virtual machines, such as the host status, basic performance indicators, as well as VM status and capacity consumption. This information is collected by executing a set of static probes provided by OpenNebula. The information is sent according to the following process: each host periodically sends monitoring data to the front-end which collects it and processes it in a dedicated module. This model is highly scalable and its limit (in terms of number of VMs monitored per second) is bounded to the performance of the server running on and the database server. OpenNebula also brings resource quota management to allocate, track and limit resource utilization/consumption. https://opennebula.org/ Shares the functionality of tracing all events and user actions impacting a data entity throughout its lifecycle (from its creation to its disposal). It can be used to reproduce a certain state of a data entity at a certain moment in time. Logging = To record details of information or events in an organized record-keeping system, usually sequenced in the order in which they occurred. Based on ISACA https://www.isaca.org The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Graylog2 - open source log management platform Graylog2 is an open source log management platform. Each message is saved in an Elasticsearch database and a web interface allows to manage and analyse the logs. Graylog2 is divided into two parts: graylog2-server and graylog2-web-interface. The first is a Java application that accepts messages on different protocols: UDP, TCP, GELF, AMQP... Each message is analysed and saved in the Elasticsearch database. A Rest API is also integrated into the tool and is used in particular by the web-interface part. This allows to manage users, streams and dashboards. Some possible uses: • Centralization of the logs: several types of inputs: syslog, GELF, raw... Rather than having to connect to each of the servers to consult the error logs, they can be configured to send all the messages in Graylog2. • Debug application • Exception handling • Log analysis For example, it can easily list the clients who are still using the deprecated version of an API. Another search can e.g. allow you to list the largest consumers or the most used parts of an API. Graylog Enterprise is built on top of the Graylog open source platform and offers additional features: • Archiving: automatically archive the data that are not searched through very often. Store this data on more cost-effective, slower hard disks and make it available for search in Graylog only when needed. • Audit Log: Graylog Enterprise also offers Audit Log capabilities. Audit Log records and stores actions taken by a user or administrator that make changes in the Graylog system. https://www.graylog.org/ DEFINITION: Data Warehouse Service ABB is an Application Service transforming raw data and storing them in query-able forms. It is an information system that contains historical and commutative data from single or multiple sources. It simplifies reporting and analysis process of the organization. Source: ISA2 - EIA Action INTEROPERABILITY SALIENCY: IoP Dimension: Behavioral IoP The Data Warehouse Service ABB  is salient for technical interoperability because it provides and shares the functionality for the short-term or medium-term preservation of records and information in electronic form in order to ensure their temporal egibility, reliability and integrity and to ease their management as stated in the EIF: "Legislation requires that decisions and data are stored and can be accessed for a specified time. This means that records and information in electronic form held by public administrations for the purpose of documenting procedures and decisions must be preserved and be converted, where necessary, to new media when old media become obsolete. The goal is to ensure that records and other forms of information keep their legibility, reliability and integrity and can be accessed as long as needed subject to security and privacy provisions." EXAMPLES: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): ESSnet: The overall objective of this ESSnet is to provide assistance in the development of more integrated databases and data production systems for business statistics in Member States. Therefore the ESSnet has to work on issues that are common for the majority of the ESS NSIs when applying a data warehousing approach for statistics. Its general objectives are: - Review of current best practices in integrated business data systems - Identification of problems and solutions in current practices and the opportunities that a data warehouse might provide - Examination of ways in which data can be combined to support new outputs - Provision of recommendations on how the ESS can improve data warehousing Source: (https://ec.europa.eu/eurostat/cros/content/data-warehouse-sga1_en) Shares the functionality of categorisation of electronic documents in order to i) store, ii) publish and iii) reuse these documents in multiple contexts. For a differentiation between ERMS and EDMS visit section 10.3 of Moreq: http://ec.europa.eu/archival-policy/moreq/doc/moreq_en The definition of a Record Management Service includes a differentiation towards record management and e-archiving. Based on the EC Document and Archival Policy https://ec.europa.eu/info/about-european-union/principles-and-values/transparency/access-documents/information-and-document-management_en The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Council of Europe - Documents, Records and Archives You will find on the Documents, Records and Archives website information about the Council of Europe's documents, records and archives, how they are organised and how to access them, whatever their format (audio-visual, electronic, paper or web archives): - information about the Council of Europe's documents, records and archives, how they are organised and how to access them, whatever their format (audio-visual, electronic, paper or web archives) - information on the rules and procedures governing access - search tools and other professional tools - a timeline with a selection of themes related to the construction of the Council of Europe and the personalities involved (being developed) - an information management guidance page https://www.coe.int/en/web/documents-records-archives-information/home Shares the functionality of the categorisation of information resources so that they can be stored, published and reused in multiple contexts. Based on DAMA http://www.dama.org/ Syn. CMS The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): CROS Portal The CROS Portal is a content management system based on Drupal and stands for "Portal on Collaboration in Research and Methodology for Official Statistics". The CROS Portal is dedicated to the collaboration between researchers and Official Statisticians in Europe and beyond. It provides a working space and tools for dissemination and information exchange for statistical projects and methodological topics. Services provided include hosting of statistical communities, repositories of useful documents, research results, project deliverables, CVs of experts in statistical relevant areas, and discussion fora on different topics like the future research needs in Official Statistics. https://ec.europa.eu/eurostat/cros/ Shares the functionalities of i) administration of services and/or systems and ii) monitoring of services and/or systems with the goal of ensuring that these solutions run in an efficient and effective way. Source: ISA2 – EIA Action Syn. Data Center Infrastructure Management The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Nagios Nagios is a powerful monitoring system that enables organizations to identify and resolve IT infrastructure problems before they affect critical business processes. It provides the following features: • Comprehensive Monitoring: o Capabilities to monitor applications, services, operating systems, network protocols, system metrics and infrastructure components o Powerful script APIs allow easy monitoring of in-house and custom applications, services, and systems • Problem Remediation o Alert acknowledgments provide communication on known issues and problem response o Event handlers allow automatic restart of failed applications and services • Reporting o Availability reports o Historical reports provide record of alerts, notifications, outages, and alert response • Extendable Architecture o Multiple APIs permit the integration with in-house and third-party applications o Hundreds of community-developed add-ons extend core Nagios functionality • Visibility & Awareness o Centralized view of entire monitored IT infrastructure o Detailed status information available through web interface o Fast detection of infrastructure outages o Alerts can be delivered to technical staff via email or SMS o Escalation capabilities • Proactive Planning o Trending and capacity planning add-ons permit the follow-up of aging infrastructure o Scheduled downtime allows for alert suppression during infrastructure upgrades • Multi-Tenant Capabilities o Multi-user access to web interface allows stake holders to view infrastructure status o User-specific views ensures clients see only their infrastructure components • Stable, Reliable Platform o Over 10 years of active development o Scales to monitor thousands of nodes o Failover capabilities ensure non-stop monitoring of critical IT infrastructure components • Customizable Code o Open Source Software o Full access to source code o Released under the GPL license • Active community o Over 1 million+ users worldwide o Hundreds of add-ons https://www.nagios.org/ A data standard is a structural metadata specification that describes or defines other data [ISO111179]. Structural metadata indicates how compound objects are put together [NISO]. It can consist of among others data models, reference data, and identifier schemas. DESCRIPTION: Open data refers to the practice of publishing (raw) data in a way that is accessible, reusable, machine readable and licensed permissively. It can be generated by a wide range of parties, including public authorities, the semi-public sector, businesses and the public. In the case of public authorities, such as European Union organisations, making their data available for public reuse supports economic development, openness and transparency. Source: EU Open Data guide http://bookshop.europa.eu/en/eu-open-data-pbOA0416036/downloads/OA-04-16-036-EN-C/OA0416036ENC_002.pdf?FileName=OA0416036ENC_002.pdf&SKU=OA0416036ENC_PDF&CatalogueNumber=OA-04-16-036-EN-C INTEROPERABILITY SALIENCY: The Open Data ABB is salient for semantic interoperability because it is a part of the basic components of the EIF's conceptual model for integrated public services. Opening of public sector datasets for sharing and reuse is encouraged by the Directive on the reuse of public sector information, which provides a common legal framework for reuse of public sector data as stated in the EIF recommendation n° 2: "Publish the data you own as open data unless certain restrictions apply." EXAMPLES: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): European Data Portal The European Data Portal harvests the metadata of Public Sector Information available on public data portals across European countries. Information regarding the provision of data and the benefits of re-using data is also included. Within the Portal, sections are dedicated to: • Searching datasets: Categories have been established to structure the metadata harvested from the various countries. These categories follow the revision of the DCAT Application Profile and have been mapped against the Eurovoc Thesaurus. • Providing Data: This section gives an insight into understanding Open Data from the perspective of a data provider. In addition, instructions are offered for those who wish their data portal to be harvested by the European Data Portal. • Using Data: How Open Data is being used, as well as the economic benefits of Open Data are detailed in this section. • Training and Library: eLearning modules about Open Data as well as training guides and a knowledge base referencing publications around Open Data and featured projects. Portals can be national, regional, local or domain specific. They cover the 28 EU Member States, EEA, countries involved in the EU's neighbourhood policy and Switzerland. https://www.europeandataportal.eu/ Data that covers the business information related to business transactions and information exchanges. Based on DAMA DM_BOK http://www.dama.org The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): DATA EXCHANGE STANDARDS FOR REGISTRY SYSTEMS UNDER THE KYOTO PROTOCOL - TECHNICAL SPECIFICATIONS This section of the Technical Specifications addresses the messages and content requirements necessary to support submissions of unit transactions by registries and the validation of those transactions by the ITL. The unit transactions either involve the transfer of ownership of a unit, a change in an attribute of a unit, or the replacement of a tCER or lCER. This section will describe the data exchange flow, the responsibilities of registries, and the responsibilities of the ITL in order to complete a unit transaction. The following unit transactions are described: • Issuance; • Conversion; • External Transfers; • Cancellation (Internal Transfer); • Replacement (Internal Transfer); • Retirement (Internal Transfer); • Carry-over; and • Expiry Date Change. http://unfccc.int/kyoto_protocol/registry_systems/itl/items/4065.php DESCRIPTION: A trusted authentic source of information under the control of an appointed public administration or organisation appointed by government. According to the European Interoperability Framework, base registries are: “reliable sources of basic information on items such as persons, companies, vehicles, licenses, buildings, locations and roads” and “are authentic and authoritative and form, separately or in combination, the cornerstone of public services”. Source: the New EIF http://eur-lex.europa.eu/resource.html?uri=cellar:2c2f2554-0faf-11e7-8a35-01aa75ed71a1.0017.02/DOC_3&format=PDF INTEROPERABILITY SALIENCY: The Base Registry ABB is salient for semantic interoperability because it includes "authorative sources of information", that need to be made available. EIF's includes base registries in the conceptual model for integrated public services, and describes it as "the cornerstone of European public service delivery". EIF gives several recommendations on how to manage and interact with base registries (recommendation 37, 38, 39 and 40). EXAMPLES: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Belgian national register The National Register refers to the information processing system which records, stores and communicates information relating to the identification of natural persons ie citizens. It is therefore a central database in which are recorded: • all Belgians residing in Belgium; • all Belgians residing abroad who register in the population registers held in Belgian diplomatic missions or consular posts abroad; • all foreigners residing in Belgium who are admitted or authorized to settle or reside in the Kingdom; • all foreigners (and their family members) who declare themselves refugees or who are seeking recognition of refugee status. The municipalities (and the Immigration Office for the last category of the population) are responsible for recording the information. As a pillar of e-government, the National Register ensures the sharing of authentic data identifying individuals between different public services with limited access to such data. The Sectorial Committee of the National Register established within the Commission for the Protection of Privacy is competent to authorize access to the information of the National Register or the communication thereof. https://www.ehealth.fgov.be/fr/ehealthplatform A Data Standard Catalogue is a catalogue of Data Standards. DESCRIPTION: A resource for purposes such as discovery and identification. It can include elements such as title, abstract, author, and keywords. Source: http://www.niso.org/publications/press/UnderstandingMetadata.pdf INTEROPERABILITY SALIENCY: The Descriptive Metadata ABB is salient for semantic interoperability because it facilitates opening and sharing data by providing the appropriate format, description of the content, high level of quality in order to achieve interoperability as stated in the EIF recommendation n° 42: "[..] Ensure that open data is accompanied by high quality, machine-readable metadata in non-proprietary formats, including a description of their content, the way data is collected and its level of quality and the licence terms under which it is made available. The use of common vocabularies for expressing metadata is recommended." EXAMPLES: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): ISA2 Core Vocabularies - Core Criterion and Core Evidence Vocabulary - Evidence metadata Evidences are resources and can have associated metadata. The DCMI Type Vocabulary can be used for providing a list of evidences that can be submitted for satisfying a specific criterion. Note. Initially developed in 2002, the DCMI Type Vocabulary provides a general, cross-domain list of approved terms that may be used as values for the Type element to identify the genre of a resource. Type includes terms describing general categories, functions, genres, or aggregation levels for content. https://joinup.ec.europa.eu/sites/default/files/distribution/2016-12/core_evidence_and_core_criterion_vocabulary_version_1.0.0.docx http://dublincore.org/documents/dcmi-type-vocabulary/ Definition: Data Persistence ABB is an Application Component that enables the implementation of components that are responsible for managing the storage and retrieval of data within an application. It provides an interface for storing and retrieving data from a database, file system, or other storage medium. Source: Inspired in European Comision Data Strategy Source reference: https://commission.europa.eu/strategy-and-policy/priorities-2019-2024/europe-fit-digital-age/european-data-strategy_en Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/DataPersistenceApplicationComponent LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:DataPersistenceApplicationComponent Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Context Broker as a CEF Building Block https://ec.europa.eu/digital-building-blocks/wikis/download/attachments/82773424/Context%20Broker%20Brochure.pdf?version=1&modificationDate=1558016168498&api=v2 Interoperability Saliency: The Data Persistence Application Component ABB is salient for technical interoperability because it is can be part of a digital public service to store, and retrieve data within specific applications or systems. It is the basis that realises the Data Persistence Service by providing an interface to manage data and then supporting interoperability through public services. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/DataPersistenceApplicationComponent EIF Layer: TechnicalApplication Definition: Artificial Intelligence ABB is an Application Component that enables the implementation of algorithms, machine learning, and deep learning techniques to enable machines to perform tasks that typically require human-like intelligence, such as perception, reasoning, learning, and decision-making Source: European Comision Source reference: https://digital-strategy.ec.europa.eu/en/library/definition-artificial-intelligence-main-capabilities-and-scientific-disciplines Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/ArtificialIntelligenceApplicationComponent LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:ArtificialIntelligenceApplicationComponent Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): PyTorch is a machine learning framework based on the Torch library, used for applications such as computer vision and natural language processing, originally developed by Meta AI and now part of the Linux Foundation umbrella. It is free and open-source software released under the modified BSD license. Although the Python interface is more polished and the primary focus of development, PyTorch also has a C++ interface. https://pytorch.org/ Interoperability Saliency: The Artificial Intelligence Application Component ABB is salient for technical interoperability because it provides tools and components that are able to perform operations that would require human intervention such as perception, reasoning, learning, and decision-making. By training artificial intelligence components, digital public services could reach an additional level of maturity increasing efficiency and effectiveness on interoperable processes without requiring human intervention. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/ArtificialIntelligenceApplicationComponent EIF Layer: TechnicalApplication Definition: Knowledge Discovery ABB is an Application Component that enables the implementation of processes where a lot of data manipulation tools with different characteristics have to be used together to reach the goal of previously unknown, potentially useful information extraction. Source: Inspired in EUROSTAT Source reference: https://ec.europa.eu/eurostat/statistics-explained/index.php?title=Glossary:Knowledge-intensive_services_(KIS) Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/KnowledgeDiscoveryApplicationComponent LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:KnowledgeDiscoveryApplicationComponent Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): CELLAR. Cellar metadata is stored in a knowledge graph, and more specifically in a triple store. A SPARQL interface is used to query the metadata. https://op.europa.eu/en/web/cellar/cellar-data/metadata/knowledge-graph Interoperability Saliency: The Knowledge Discovery Application Component ABB is salient for technical interoperability because it contributes to performing a highly complex process where a lot of data manipulation tools with different characteristics have to be used together to reach the goal of previously unknown, potentially useful information extraction. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/KnowledgeDiscoveryApplicationComponent EIF Layer: TechnicalApplication Definition: Data Publication ABB is an Application Component that implements the functionality of making data publicly available and discoverable for reuse by other public administration services. Source: ISA2 Source reference: https://ec.europa.eu/isa2/sites/default/files/docs/publications/isa2-actions-phase2_-_poc_-_wp1_specifications_en.pdf Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/DataPublicationApplicationComponent LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:DataPublicationApplicationComponent Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): CKAN - CKAN is a data publication tool that makes data accessible by providing tools to streamline publishing, sharing, finding and using data. This is a tool for making open data websites. It helps you manage and publish collections of data. It is used by national and local governments, research institutions, and other organizations that collect a lot of data. Once your data is published, users can use its faceted search features to browse and find the data they need and preview it using maps, graphs and tables – whether they are developers, journalists, researchers, NGOs, citizens, or even your staff. CKAN is open-source and free software, with an active community of contributors who develop and maintain its core technology. CKAN is modified and extended by an even larger community of developers who contribute to a growing library of CKAN extension. https://ckan.org/ Interoperability Saliency: The Data Pubblication Component ABB  is salient for technical interoperability because it provides the implementation of the functionalities to make public data freely available for use and reuse by others unless restriction aoply as stated in the EIF recommendation n.2: "Publish the data you own as open data unless certain restrictions apply." Interoperability Dimension: Structural IoP Viewpoint: Interoperability Privacy viewpoint Additional identifier: http://data.europa.eu/dr8/DataPublicationApplicationComponent EIF Layer: TechnicalApplication Definition: Blockchain ABB is an Application Component that implements a set of rules and processes to enable secure and transparent transactions and record-keeping for sharing of information, enabling permanent, immutable, and transparent recording of data and transactions. Source: Inspired in European Blockchain Strategy Source reference: https://digital-strategy.ec.europa.eu/en/library/european-blockchain-strategy-brochure Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/BlockchainApplicationComponent LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:BlockchainApplicationComponent Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Fishcoin Project, is a project using Blockchain technologies for seafood traceability. https://fishcoin.co/ Interoperability Saliency: The Blockchain Application Component ABB is salient for interoperability because it implements a set of elements needed and used by blockchain services. Those aspects are peer network, smart contracts, membership, events, ledger, system integration, wallet, and system management. All listed components can be part of a digital public service enhancing trustability and enabling interoperability in a secure and reliable way. Additional information: In the creation of the Blockchain component, several actors such as developer, user, architect, regulator, operator, membership services, etc. are present in a blockchain that provides a solution to a blockchain-based business network. Each actor and component present in a blockchain plays a major role to make the network more secure and reliable. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/BlockchainApplicationComponent EIF Layer: TechnicalApplication Definition: Conformance Testing ABB is an Application Component that enables a structural and modular approach for implementing the validation of the application or service to meet the requirements of a standard or specification Source: NIST Source reference: https://www.nist.gov/itl/ssd/information-systems-group/conformance-testing Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/ConformanceTestingApplicationComponent LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:ConformanceTestingApplicationComponent Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Interoperability Testbed - The Test Bed allows users to execute predefined test cases on their systems in order to test the conformance to standards and requirements, simulate a web-service, validate content and test a complete message exchange protocol. The Testbed manages test cases and users, and orchestrates domain-specific components, the domain-specific logic is in separate components that are used via web services. Test results are provided in a standardised, machine-readable format. The Test Bed also offers a test registry and repository (TRR) to store test artefacts (assertions, test cases, validation schemas, etc.) and compile test services (validation services, simulator services, etc.). Please visit the following website for more information: https://ec.europa.eu/isa2/solutions/interoperability-test-bed_en Interoperability Saliency: The Conformance Testing Component ABB  is salient for technical interoperability because it enables the validation and verification that several solutions at one or more layers of the interoperability stack and they satisfy certain interoperability requirements. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/ConformanceTestingApplicationComponent EIF Layer: TechnicalApplication DEFINITION: HTTP(S) Load Balancer ABB is an Application Component that refers to a proxy-based Layer 7 load balancer enabling a user to run and scale your services behind a single external IP address. HTTP(S) Load Balancer distributes HTTP and HTTPS traffic to backends hosted on a variety of Cloud platforms as well as external backends connected over the internet or via hybrid connectivity. SOURCE: https://cloud.google.com/load-balancing/docs/https Definition: Authentication Middleware ABB is an Application Component that refes to the digital asset which checks for a valid identity of AuthenticationService . If no identity is present, it redirects the redirect configuration value. Source: Inspired in Gartner Source reference: https://www.gartner.com/en/information-technology/glossary/middleware Identifier: http://data.europa.eu/dr8/AuthenticationMiddlewareApplicationComponent eira:ID: ABB585 ABB name: eira:AuthenticationMiddlewareApplicationComponent Definition: Shared Platform ABB is an Application Component supporting the reuse and efficiency, enabling organisations to leverage common sets of tools. his approach helps organizations optimize costs, improve resource utilisation, and foster innovation and collaboration. Shared Platforms facilitate better data management and exchange, provide scalability and flexibility, and help maintain consistency and compliance across different applications and services within the enterprise. Source: Inspired in definitions from referent companies of IT sector Last modification: 2023-11-20 Identifier: http://data.europa.eu/dr8/SharedPlatformApplicationComponent LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:SharedPlatformApplicationComponent eira:iopSaliency: The Shared Platform ABB is a key interoperability enabler because it supports to achieve technical interoperability with public policy goals convergence value by all in all enabling i) the provision/consumption of back-office digital public services, ii) the exchange of data, information, and knowledge between digital public services and individuals , and iii) collaboration between digital public services. Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): The Commission proposed a framework for a European Digital Identity which will be available to all EU citizens, residents, and businesses in the EU. Citizens will be able to prove their identity and share electronic documents from their European Digital Identity wallets with the click of a button on their phone. They will be able to access online services with their national digital identification, which will be recognised throughout Europe. Very large platforms will be required to accept the use of European Digital Identity wallets upon request of the user, for example to prove their age.(https://ec.europa.eu/commission/presscorner/detail/en/IP_21_2663) Additional information: This convergence power is based on the instrumental nature and efficiencies of these resources for enabling common problem-solving approaches. The degree of achievement could range from an ideal perfect shared platform (i.e. no interoperability barriers from the technical perspective) to an imperfect or even null shared platform (i.e. some interoperability barriers from the technical perspective). The level of technical interoperability will constrain digital public services cross levels in a public administration, cross public administrations, and cross borders. The shared platform enables: i) structural interoperability with technical resources supporting reusing and/or sharing of digital public services (i.e. service registry service); ii) behavioural interoperability with technical resources supporting exchanging capabilities of data, information or knowledge with internal/external peers (i.e. Technical interfaces); and iii) governance interoperability with technical resources supporting the assurance and control of collaboration with internal/external peers exchanging data, information, and knowledge(i.e. Technical Interoperability Agreements). Shared Platform offers a harmonised repository of business and technological resources that are essential for the dissemination of unique business functionalities. It is the cornerstone of a digital ecosystem, invariably interfacing with constituents through APIs or providing bespoke connectivity solutions like direct data access, thus ensuring that the organisation's digital fabric is both resilient and adaptive. Interoperability Dimension: Structural IoP Viewpoint: Interoperability Security viewpoint Additional identifier: http://data.europa.eu/dr8/SharedPlatformApplicationComponent EIF Layer: TechnicalApplication Definition: Audit ABB is an Application Component that enables the implementation of the procedural services for monitoring a building block, ensuring security or compliance with standards, regulations and best practices Source: Inspired in SIMPL Source reference: https://digital-strategy.ec.europa.eu/en/news/simpl-cloud-edge-federations-and-data-spaces-made-simple Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/AuditApplicationComponent LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:AuditApplicationComponent Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Activiti audit feature - The audit feature of Activiti archives all process instances, activity instances, keeps variable values continuously in sync and all form properties that are submitted so that all user interaction through forms is traceable and can be audited. Authenticated users who submitted the forms are accessible in the history as well as for start forms and task forms. https://www.activiti.org/userguide/#historyFormAuditPurposes Interoperability Saliency: The Audit Component ABB  is salient for technical interoperability because it allows the implementation of audit policies as stated in the EIF: "Public administrations should ensure that a 'data access and authorisation plan’ which determines who has access to what data and under what conditions, to ensure privacy. Unauthorised access and security breaches should be monitored and appropriate actions should be taken to prevent any recurrence of breaches" Interoperability Dimension: Structural IoP Viewpoint: Interoperability Security viewpoint Additional identifier: http://data.europa.eu/dr8/AuditApplicationComponent EIF Layer: TechnicalApplication Definition: Interoperable Digital Solution ABB is an Application Component that enables the cooperation between public services, systems and data across organisational and national boundaries Source: ISA2 Source reference: https://ec.europa.eu/isa2/eif_en/ Additional information: This ABB also corresponds to the delivery of a digital public service, in fulfilment of a shared European legislation framework, being managed according a shared governance framework, accessing semantic assets in a shared knowledge base and using digital resources of a shared platform enabling cross-border/cross-organization exchange of data, information, and knowledge indistinctly between public administrations, businesses and citizens in support to the implementation and advancement of an EU, national or local public policy. Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): eDelivery - Supporting secure and reliable exchange of data and documents - eDelivery is a network of nodes for digital communications. It is based on a distributed model where every participant becomes a node using standard transport protocols and security policies. eDelivery helps public administrations to exchange electronic data and documents with other public administrations, businesses and citizens, in an interoperable, secure, reliable and trusted way. eDelivery is one of the building blocks of the European Commission's Connecting Europe Facility (CEF). These building blocks are reusable specifications, software and services that will form part of a wide variety of IT systems in different policy domains of the EU. The CEF eDelivery building block is based on the AS4 messaging protocol, open and free for all, developed by the OASIS standards development organisation. To ease its adoption in Europe, eDelivery uses the AS4 implementation guidelines defined by the Member States in the e-SENS Large Scale Pilot. Organisations must install an Access Point, or use a Service Provider, to exchange information with the AS4 messaging protocol.(https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/eDelivery) IoP Dimension: Structural IoP, Behavioral IoP LOST view: Technical view - application Interoperability saliency: The Interoperable Digital Solution Application Component ABB is salient for technical interoperability because it constitutes the digital public service interoperable with other digital public services, across organisations and national boundaries. Identifier: http://data.europa.eu/dr8/InteroperableDigitalSolutionApplicationComponent ABB name: eira:InteroperableDigitalSolutionApplicationComponent EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2022-18-01 eiraID: ABB519 Definition: e-Archiving ABB is an Application Component that enables the implementation of components for the permanent or long-term storage of selected (by an authority) electronic documents or information for preservation purposes like their enduring research value and a memory aid. Source: ISA2 - EIA Action Source reference: https://ec.europa.eu/isa2/actions/towards-european-interoperability-architecture_en/ Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/E-ArchivingApplicationComponent LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:E-ArchivingApplicationComponent Synonym: Preservation Service Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): CEF eArchiving - eArchiving provides the core specifications, software, training and knowledge to tackle the challenge of short, medium and long-term data management and reuse in a sustainable, authentic, cost-efficient, manageable and interoperable way.(https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/eArchiving) Interoperability Saliency: The e-Archiving Component ABB  is salient for technical interoperability because it provides the implementation of the functionalities for the long-term or permanent preservation of records and information in electronic form in order to ensure their temporal egibility, reliability and integrity as stated in the EIF: "Legislation requires that decisions and data are stored and can be accessed for a specified time. This means that records and information in electronic form held by public administrations for the purpose of documenting procedures and decisions must be preserved and be converted, where necessary, to new media when old media become obsolete. The goal is to ensure that records and other forms of information keep their legibility, reliability and integrity and can be accessed as long as needed subject to security and privacy provisions." Additional information: The EIRA© differentiates between document management, record management and e-archiving as follows: • Document management is primarily about day-to-day use of electronic documents (create/update/delete/versioning) within the operational environment; • Record management is primarily about ensuring that information (e.g. in form of an electronic document or database record) is available for business and legal purposes (e.g. to proof and track the handling of contracts). If an electronic document or information is becoming a record (an authority declares it as a record) that electronic document or information needs to be handled by the record management service (based on specific business or legal reasons (e.g. contract negotiation)); • e-Archiving is primarily about storing records which have been selected (by an authority) for permanent or long-term preservation due to their enduring research value and as a memory aid. An electronic document or information which a) is managed by the document management service or the record management service and b) is no longer needed for business or legal purposes or day-to-day activities, and c) still has value for research purposes or as a memory aid, the electronic document should be managed by the e-archiving service”. Interoperability Dimension: Structural IoP Viewpoint: Interoperability Privacy viewpoint Additional identifier: http://data.europa.eu/dr8/E-ArchivingApplicationComponent EIF Layer: TechnicalApplication Definition: Privacy ABB is an Application Component that enables the implementation of functionalities such as storing, securing, anonymising, pseudonymising, rectifying and erasing personal data. Source: ePrivacy Regulation Source reference: https://digital-strategy.ec.europa.eu/en/policies/eprivacy-regulation Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/PrivacyApplicationComponent LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:PrivacyApplicationComponent Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): SOLVIT - Solvit is a mailbox service for the access, rectification or deletion of personal data.(http://ec.europa.eu/solvit/privacy-statement/#maincontentSec8) Interoperability Saliency: The Privacy Component ABB  is salient for interoperability because "security and privacy are primary concerns in the provision of public services" (EIF) and, as stated in EIF Recommendation 15: "Define a common security and privacy framework and establish processes for public services to ensure secure and trustworthy data exchange between public administrations and in interactions with citizens and businesses." Interoperability Dimension: Structural IoP Viewpoint: Interoperability Privacy viewpoint Additional identifier: http://data.europa.eu/dr8/PrivacyApplicationComponent EIF Layer: TechnicalApplication Definition: API Management Middleware ABB is an Application Component that provides a layer of functionality between an API (Application Programming Interface) and its consumers. The middleware manages the interactions between the API and its consumers, providing features such as authentication, authorization, rate limiting, and analytics. Source: Inspired in Redhat Source reference: https://www.redhat.com/en/topics/middleware/what-is-middleware Identifier: http://data.europa.eu/dr8/AuthenticationMiddlewareApplicationComponent eira:ID: ABB585 ABB name: eira:AuthenticationMiddlewareApplicationComponent Definition: Metadata Management ABB is an Application Component that enables the implementation of components for the i) creation, ii) storage, iii) categorisation and iv) retrieval of metadata. Source: DAMA Source reference: http://www.dama.org/ Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/MetadataManagementApplicationComponent LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:MetadataManagementApplicationComponent Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Eurostat SDMX repository: The Euro SDMX Registry is Eurostat’s implementation of an SDMX registry to facilitate the exchange of statistical data and metadata by serving as a metadata repository. It stores the SDMX artefacts needed for the parties to access and interpret the content of the exchanged statistical data and metadata sets. http://ec.europa.eu/eurostat/web/sdmx-infospace/sdmx-it-tools/sdmx-registry Interoperability Saliency: The Metadata management Component ABB is an application component providing the implementation of the functionalities to manage metadata. EIF recommends to prioritise it: "Put in place an information management strategy at the highest possible level to avoid fragmentation and duplication. Management of metadata, master data and reference data should be prioritised." Interoperability Dimension: Structural IoP Viewpoint: Interoperability Privacy viewpoint Additional identifier: http://data.europa.eu/dr8/MetadataManagementApplicationComponent EIF Layer: TechnicalApplication Definition: Identification ABB is an Application Component implementing the process of verifying a user's identity based on one or more authentication factors. Source: eIDAS - REGULATION (EU) No 910/2014 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 23 July 2014 on electronic identification and trust services for electronic transactions in the internal market and repealing Directive 1999/93/EC. Source reference: (http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv%3AOJ.L_.2014.257.01.0073.01.ENG) Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/IdentificationApplicationComponent LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:IdentificationApplicationComponent Synonym: Authentication Component Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): OpenIAM Identity Manager - The OpenIAM Identity Manager automates the task of managing identities across the various devices and applications used by the enterprise. This includes applications within the enterprise such as Active Directory and Exchange, and cloud based applications such as Google Apps. OpenIAM Identity Manager provides capabilities such as: • Provisioning, De-provisioning, Workflow; • Password Management, Password Policies, Synchronization; • Self-Service, allowing locked users to reset their accounts, manage their profiles, challenge response security questions; • Audit, Attestation, Reporting; • Delegated Administration.(http://www.openiam.com/products/identity-manager/idm-overview/) Interoperability Saliency: The Identification Component ABB  is salient for technical interoperability because it provides the functionalities of user authentication. Interoperability Dimension: Structural IoP Viewpoint: Interoperability Security viewpoint Additional identifier: http://data.europa.eu/dr8/IdentificationApplicationComponent EIF Layer: TechnicalApplication Definition: Agenda Management Component ABB is an Application Component that enables the implementation of the procedures to create, distribute and manage events and meetings for public administration and services Source: Inspired in Public Works and Goverment Services Canada Source reference: https://buyandsell.gc.ca/cds/public/2016/11/23/c7b27e0ac41ad50ffae2f12b0a837875/ABES.PROD.PW_PWZ.B014.E10051.ATTA001.PDF Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/AgendaManagementApplicationComponent LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:AgendaManagementApplicationComponent Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Innovation Public Procurement Broker (IPPB). https://ec.europa.eu/futurium/en/system/files/ged/action_7_innovation_public_procurement_broker_guideline.pdf Interoperability Saliency: The Agenda Management Application Component ABB is salient for technical interoperability because it implements the orchestration of different events within digital public services within specific platforms but can be reused and extended in a high-level approach to enable interoperability of digital public services and the different delivery models. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/AgendaManagementApplicationComponent EIF Layer: TechnicalApplication Definition: Forms Management ABB is an Application Component that enables the implementation of i) dynamic creation, ii) distribution and ii) analysis of forms and online surveys. Source: ISA2 - EIA Action Source reference: https://joinup.ec.europa.eu/taxonomy/term/http_e_f_fdata_ceuropa_ceu_fdr8_fFormsManagementComponent Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/FormsManagementApplicationComponent LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:FormsManagementApplicationComponent Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Form Tools - Form Tools is a forms framework written in PHP and MySQL. You download and install the script on your own website. At its heart, Form Tools is a web form creator, processor, data storage and access script. It was originally designed to work with any existing web form, but has since been expanded to create forms automatically as well. Form Tools is extremely versatile in how it integrates with your forms. You can use the bundled Form Builder module to create the forms automatically on your website (no programming or HTML skills necessary); you can use the PHP API to integrate your own custom form with the script; or you can simply POST your form to Form Tools, and just use it to store the form data. Anything goes! You can read about the different integration methods / form creation methods here. Form Tools works by creating custom database tables to store your unique form data. It provides a range of functionality customized to your data set, such as allowing you to view, update, cross-reference and export your submission data, create subsets of your data for viewing/editing by client accounts, data visualizations, and much more. https://formtools.org/ Interoperability Saliency: The Forms Management Component ABB  is salient for technical interoperability because it provides the implementation of the functionalities of dynamic creation, distribution and analysis of forms and online surveys as stated in the EIF: " Catalogues help others to find reusable resources (e.g. services, data, software, data models). Various types of catalogue exist, e.g. directories of services, libraries of software components, open data portals, registries of base registries, metadata catalogues, catalogues of standards, specifications and guidelines. Commonly agreed descriptions of the services, data, registries and interoperable solutions published in catalogues are needed to enable interoperability between catalogues." Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/FormsManagementApplicationComponent EIF Layer: TechnicalApplication Definition: Orchestration ABB is an Application component that enables the coordination and management of the execution of multiple components or services within an application or system. Source: W3C Source reference: https://www.w3.org/TR/ws-arch/ Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/OrchestrationApplicationComponent LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:OrchestrationApplicationComponent Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Activiti - Activiti is an open-source workflow engine written in Java that can execute business processes described in BPMN 2.0. Activiti supports open standards such as BPMN and DMN with open REST APIs for demanding human- and system-centric processes. It provides business intelligence and audit logs features for free. And with building the solution on business processes, Activiti help to structure the software, think about user tasks, external systems and timers that need to be managed, think about transaction boundaries of the application. Building that kind of features becomes easier when structuring an application around a business process. Managing wait states, timers and asynchronous continuations becomes easier. A business process can express that structure more compact than working with the fundamental instruments that the Java platform offers like JDBC and JMS. Activiti also makes possible to link in Java or scripting for jobs. https://www.activiti.org/ Interoperability Saliency: The Orchestration Component ABB  is salient for technical interoperability because it provides a set of various methods to manage existing business processes or define and establish new ones. BPM components also execute business process documented through accepted modelling techniques, as recommended by the EIF n.28: "Document your business processes using commonly accepted modelling techniques and agree on how these processes should be aligned to deliver a European public service." Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/OrchestrationApplicationComponent EIF Layer: TechnicalApplication Definition: Machine Translation ABB is an Application Component that enables the implementation of an automated translation of text, metadata and concept classes or nomenclatures Source: CEF Automated Translation Source reference: https://ec.europa.eu/digital-single-market/en/news/tools-and-resources-cef-automated-translation Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/MachineTranslationApplicationComponent LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:MachineTranslationApplicationComponent Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): "CEF Digital - eTranslation building block: eTranslation is a Connecting Europe Facility (CEF) building block provided by the European Commission (EC). eTranslation provides a web-user interface for direct use by individuals (human-to-machine).(https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/eTranslation) Interoperability Saliency: The Machine Translation Component ABB  is salient for technical interoperability because it provides the implementation of functionalities for cross-lingual functionality by providing automated translation of text, metadata and concept classes or nomenclatures as stated in the EIF recommendation n°16: "Use information systems and technical architectures that cater for multilingualism when establishing a European public service. Decide on the level of multilingualism support based on the needs of the expected users." Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/MachineTranslationApplicationComponent EIF Layer: TechnicalApplication Definition: Public Administration Single Window Component ABB is an Application Component that enables the implementation of the procedures to submit information and documents with a single entry point to fulfil all regulatory requirements. Source: United Nations Source reference: https://tfig.unece.org/contents/single-window-concept.htm Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/PublicAdministrationSingleWindowApplicationComponent LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:PublicAdministrationSingleWindowApplicationComponent Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Mi Carpeta Ciudadana Carpeta Ciudadana is a personal online space that facilitates your relationship with public administrations. https://carpetaciudadana.gob.es/carpeta/clave.htm Interoperability Saliency: The Public Administration Single Window Application Component ABB is salient for technical interoperability because it implements the platform that realises the service, meaning that includes the tool for administrations and stakeholders (citizens and businesses) to share documentation, information or relevant data. As the platform and services must be compliant with all regulatory aspects depending on the domain of the public service, it can enable interoperability between other public services by allowing regulation compliance of the data provided. Interoperability Dimension: Behavioral IoP Additional identifier: http://data.europa.eu/dr8/PublicAdministrationSingleWindowApplicationComponent EIF Layer: TechnicalApplication Definition: Data Virtualization ABB is an Application Component that implements the functionality of retrieving and manipulating data without requiring technical details about the data format or location. Source: Joinup Source reference: https://joinup.ec.europa.eu/sites/default/files/inline-files/Data%20visualisation%20service%20definition.pdf Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/DataVirtualizationApplicationComponent LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:DataVirtualizationApplicationComponent Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Virtuoso. Virtuoso Universal Server is modern platform built on existing open standards that harnesses the power of Hyperlinks (functioning as Super Keys) for breaking down data silos that impede both user and enterprise ability. For example, Virtuoso's core SQL & SPARQL powers many Enterprise Knowledge Graph initiatives just as it does DBpedia and a majority of nodes in the Linked Open Data Cloud -- the world's largest publicly accessible Knowledge Graph. https://big-data-test-infrastructure.ec.europa.eu/service-offering/virtuoso_en Interoperability Saliency: The Data Virtualization Component ABB is salient for technical interoperability because it realises the services established and defined by the Data Virtualization Service ABB, collaborating with enabling interoperability between public services that generate, process or consume data. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/DataVirtualizationApplicationComponent EIF Layer: TechnicalApplication Definition: Trust Service Provisioning ABB is an Application Component that enables the creation, verification, or validation of electronic signatures, time stamps, seals, electronically registered delivery services, and certificates. Source: eIDAS Source reference: http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv%3AOJ.L_.2014.257.01.0073.01.ENG Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/TrustServiceProvisioningApplicationComponent LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:TrustServiceProvisioningApplicationComponent Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): e-TrustEx - Open e-TrustEx is a platform offered by the Directorate-General for Informatics of the European Commission to Public Administrations at European, national and regional level to set up secure exchange of natively digital documents from system to system via standardized interfaces. Open e-TrustEx provides a set of generic web services, which Public Administrations can use to connect heterogeneous applications, removing the need for complex point-to-point connections. http://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX%3A52016SC0279 Interoperability Saliency: The Trust Service Provisioning Component ABB  is salient for technical interoperability because it provides the implementation of the functionalities of information exchange between between administrations, businesses and citizens (e-signature and e-seal creation, verification,validation and preservation, timestamping creation, verification and validation, identity management, etc.) as stated in the EIF recommendation n°47: "Use trust services according to the Regulation on eID and Trust Services as mechanisms that ensure secure and protected data exchange in public services." Additional information: A ‘trust service’ means an electronic service normally provided for remuneration which consists of these functionalities: i) the creation, verification, and validation of electronic signatures, electronic seals or electronic time stamps, electronic registered delivery services and certificates related to those services, or; ii) the creation, verification and validation of certificates for website authentication; or; iii) the preservation of electronic signatures, seals or certificates related to those services. Interoperability Dimension: Structural IoP Viewpoint: Interoperability Security viewpoint Additional identifier: http://data.europa.eu/dr8/TrustServiceProvisioningApplicationComponent EIF Layer: TechnicalApplication Definition: Data Extraction, Transformation and Loading ABB is an Application Component that enables the implementation of the process of extracting data from various sources, transforming the data to specific data models and loading the data into a target data store. Source: Inspired in definitions from referent companies of IT sector Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/DataExtractionTransformationAndLoadingApplicationComponent LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:DataExtractionTransformationAndLoadingApplicationComponent Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Eurostat SDMX converter - The SDMX Converter is a tool that converts statistical datasets between different formats. It is a Java application which is actively developed by Eurostat and is published as open source software. http://ec.europa.eu/eurostat/web/sdmx-infospace/sdmx-it-tools/sdmx-converter Interoperability Saliency: The Data Extraction, Transformation, and Loading Component ABB  is salient for technical interoperability because it enables the implementation of the functionalities to transform internal data structures to common and agreed interoperable formats as stated in the EIF recommendation n° 41: "Establish procedures and processes to integrate the opening of data in your common business processes, working routines, and in the development of new information systems." Interoperability Dimension: Structural IoP Viewpoint: Interoperability Privacy viewpoint Additional identifier: http://data.europa.eu/dr8/DataExtractionTransformationAndLoadingApplicationComponent EIF Layer: TechnicalApplication Definition: Schedule Management Component ABB is an Application Component that enables the implementation of the procedures to manage time and events in the achievement of the goals and delivery of public services. Source: Inspired in Public Works and Goverment Services Canada Source reference: https://buyandsell.gc.ca/cds/public/2016/11/23/c7b27e0ac41ad50ffae2f12b0a837875/ABES.PROD.PW_PWZ.B014.E10051.ATTA001.PDF Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/ScheduleManagementApplicationComponent LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:ScheduleManagementApplicationComponent Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Chronos is a replacement for cron. It is a distributed and fault-tolerant scheduler that runs on top of Apache Mesos that can be used for job orchestration. It supports custom Mesos executors as well as the default command executor. Thus by default, Chronos executes sh (on most systems bash) scripts. https://sourceforge.net/projects/chronos.mirror/ Interoperability Saliency: The Schedule Management Application Component ABB is salient for technical interoperability because it implements the orchestration of different events within digital public services within specific platforms but can be reused and extended in a high-level approach to enable interoperability of digital public services and the different delivery models. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/ScheduleManagementApplicationComponent EIF Layer: TechnicalApplication Definition: Data Exchange ABB is an Application Component that enables the implementation of the procedure to transfer data between different individuals, organizations or systems. Source: EIFv2 Source reference: http://ec.europa.eu/isa/documents/isa_annex_ii_eif_en.pdf Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/DataExchangeApplicationComponent LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:DataExchangeApplicationComponent Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Open e-TrustEx - Open e-TrustEx is a secure document exchange platform. Solution for European public administration that needs to electronically exchange information with other entities in a secure way. Open e-TrustEx is a cross-sector, open source tool that helps administrations to exchange structured and unstructured documents and to connect to pan-European e-delivery infrastructures with reduced investment. For Commission services, DG Informatics operates the e-TrustEx platform for a fee.(https://ec.europa.eu/isa2/solutions/open-e-trustex_en) Interoperability Saliency: The Data Exchange Component ABB is salient for technical interoperability because it provides the implementation of the functionalities to enable a secure and trustworthy data exchange between different ICT systems as stated in the EIF: "Define a common security and privacy framework and establish processes for public services to ensure secure and trustworthy data exchange between public administrations and in interactions with citizens and businesses." Interoperability Dimension: Behavioral IoP Viewpoint: Interoperability Security viewpoint Additional identifier: http://data.europa.eu/dr8/DataExchangeApplicationComponent EIF Layer: TechnicalApplication Definition: Access Management ABB is an Application Component implementing the process of granting rights to users and preventing the access to non-authorised users. Source: ITIL v3 Source reference: https://wiki.en.it-processmaps.com/index.php/Access_Management Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/AccessManagementApplicationComponent LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:AccessManagementApplicationComponent Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): OpenIAM Access Manager - OpenIAM Access Management solution is based on a professional open source model. This is a robust, scalable solution built with Service Oriented Architecture. It integrates seamlessly with the OpenIAM Identity Manager product to provide a comprehensive solution that allows to take control of not only who can access the systems, but what they can do once they are in there. Corporate security policy is enforced across multiple points and managed centrally to improve effectiveness and reduce administrative costs.(http://www.openiam.com/products/access-manager/overview/) Interoperability Saliency: The Access Management Component ABB  is salient for technical interoperability because it provides the implementation the functionality of allowing user to make an authorized and trusted use of IT Services, data and other assets as stated in the EIF: "Public administrations should ensure that a 'data access and authorisation plan’ which determines who has access to what data and under what conditions, to ensure privacy. Unauthorised access and security breaches should be monitored and appropriate actions should be taken to prevent any recurrence of breaches" Interoperability Dimension: Structural IoP Viewpoint: Interoperability Security viewpoint Additional identifier: http://data.europa.eu/dr8/AccessManagementApplicationComponent EIF Layer: TechnicalApplication Definition: Digital Workplace ABB is an Application Component that enables the implementation of the procedures to freely collaborate independently from the location and boundaries while maintaining high-security standards and increasing productivity and efficiency. Source: European Comission Source reference: https://ec.europa.eu/info/publications/digital-workplace-strategy_en Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/DigitalWorkplaceApplicationComponent LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:DigitalWorkplaceApplicationComponent Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Set of IT tools used by European Commission officials, workers, etc. There is a new strategy put in place by the Commission to improve the work of the different roles involved. https://europa.eu/digitec/news/digital-workplace-european-commission/ Interoperability Saliency: The Digital Workplace Application Component ABB is salient for technical interoperability because it provides the components and tools that allow the free collaboration of staffing people while maintaining high-security standards. Interoperability Dimension: Behavioral IoP Additional identifier: http://data.europa.eu/dr8/DigitalWorkplaceApplicationComponent EIF Layer: TechnicalApplication Definition: Digital Solution Component ABB is an Application Component that enables the encapsulation of a functionality provided by an Interoperable European Solution. Source: Inspired in ArchiMate® v3 Source reference: http://pubs.opengroup.org/architecture/archimate3-doc/chap09.html Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): EU Login - EU Login is the European Commission's user authentication service. It allows authorised users to access a wide range of Commission web services and websites, using a single email address and password. EU Login implements the single sign-on functionality. https://webgate.ec.europa.eu/cas/help.html IoP Dimension: Structural IoP LOST view: Technical view - application Interoperability saliency: The Digital Solution Component ABB is salient for technical interoperability because it is a central element the EIF's conceptual model for integrated public services. it represents all the functionalities provided by an Interoperable European Solutionas as stated in the EIF: "Technical interoperability the applications and infrastructures linking systems and services." Identifier: http://data.europa.eu/dr8/DigitalSolutionApplicationComponent eira:ID: ABB624 ABB name: eira:DigitalSolutionApplicationComponent EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2022-18-01 Definition: Data Quality Component ABB is an Application Component that enables the implementation of verifying that the value of a data item comes from a given set of acceptable values. Data validation may be followed by corrective actions, such as data editing or data imputation. In statistics, imputation is the process of replacing missing data with substituted values. Source: Eurostat Data Validation Source reference: http://ec.europa.eu/eurostat/data/data-validation Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/DataQualityApplicationComponent LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:DataQualityApplicationComponent Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Hibernate Validator - Express validation rules in a standardized way using annotation-based constraints and benefit from transparent integration with a wide variety of frameworks. Application layer agnostic validation: Hibernate Validator allows to express and validate application constraints. The default metadata source are annotations, with the ability to override and extend through the use of XML. It is not tied to a specific application tier or programming model and is available for both server and client application programming. Hibernate Validator presents the following characteristics: • Extendable: Hibernate Validator offers a configurable bootstrap API as well as a range of built-in constraints. The latter can easily be extended by creating custom constraints; • Rich metadata API: Hibernate Validator gives access to constraint configuration via a metadata API facilitating, for example, tooling integration; • Reference implementation: Hibernate Validator 6.x is the reference implementation Bean Validation 2.0; • Added value: Hibernate Validator offers additional value on top of the features required by Bean Validation. For example, a programmatic constraint configuration API as well as an annotation processor which plugs into the build process and raises compilation errors whenever constraint annotations are incorrectly used. http://hibernate.org/validator/ Interoperability Saliency: The Data Quality Component ABB  is salient for technical interoperability because it allows the implementation of the functionality to validate if data received (or to be sent) is compliant with common and agreed interoperable formats as stated in the EIF recommendation n° 41: "Establish procedures and processes to integrate the opening of data in your common business processes, working routines, and in the development of new information systems." Interoperability Dimension: Structural IoP Viewpoint: Interoperability Privacy viewpoint Additional identifier: http://data.europa.eu/dr8/DataQualityApplicationComponent EIF Layer: TechnicalApplication Definition: API Catalogue ABB is an Application Component that refers to the (open) software interfaces functionalities that are aligned with the implementation structure of the digital services. Source: Inspired in Archimate© Source reference: https://pubs.opengroup.org/architecture/archimate3-doc/chap09.html#_Toc10045392 Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/APICatalogueApplicationComponent LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:APICatalogueApplicationComponent Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): RapidAPI - RapidAPI is a collection of predefined APIs that are free to test, specifically updated for 2021. https://rapidapi.com/collection/list-of-free-apis Interoperability Saliency: The API Catalogue Catalogue Application Component ABB is salient for interoperability because the component is relevant for the software interfaces functionalities aligned with the implementation structures of solutions and digital public services. Those features and functionalities enable data consumption, processing and provision between digital public services. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/APICatalogueApplicationComponent EIF Layer: TechnicalApplication Definition: Service Registry ABB is an Application Component that enables the registering of system services within a catalogue to facilitate the discovery of services. Source: ISA2 - EIA Action Source reference: http://data.europa.eu/eli/dec/2015/2240/oj Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/ServiceRegistryApplicationComponent LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:ServiceRegistryApplicationComponent Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): jUDDI - jUDDI is an open source Java implementation of OASIS Universal Description, Discovery, and Integration (UDDI) specification for (Web) Services. https://juddi.apache.org/ Interoperability Saliency: The Service Registry Component ABB  is a key interoperability enabler because it supports to achieve technical interoperability by provisioning and consuming back-office services as stated in the EIF recommendation n°44: "Put in place catalogues of public services, public data, and interoperability solutions and use common models for describing them." Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/ServiceRegistryApplicationComponent EIF Layer: TechnicalApplication Definition: Data Management ABB is an Application Component that enables the implementation of components to manage their data under the FAIR principles. The FAIR principles are a set of guidelines designed to ensure that scientific data and digital resources are Findable, Accessible, Interoperable, and Reusable. Source: Inspired in the Data Act Source reference: https://digital-strategy.ec.europa.eu/en/policies/data-act Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/DataManagementApplicationComponent LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:DataManagementApplicationComponent Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Oracle Data Exchange - The Data Exchange Service provides several access points to the Event Repository, allowing the user to perform queries on these events: - The Query Subscription Administration Console configures the Data Exchange Service to create queries and periodically deliver query results to designated receivers (HTTP, JMS, and AS2). The Console can also test queries before subscribing, displaying user-readable events in XML format; - A SOAP Web service allows programmatic queries. This SOAP service is based on the technically complete, but not formally ratified as of October 2006, EPCglobal EPC Information Services (EPCIS) Version 1.0 Specification.EPCglobal EPCIS 1.0 Working Draft. https://docs.oracle.com/cd/E13197_01/rfid/enterprise_server/docs20/epcis/data-exchange.html Interoperability Saliency: The Data Management Component ABB  is salient for technical interoperability because it provides and shares the functionality for the share of data: "Legislation requires that decisions and data are stored and can be accessed for a specified time. This means that records and information in electronic form held by public administrations for the purpose of documenting procedures and decisions must be preserved and be converted, where necessary, to new media when old media become obsolete. The goal is to ensure that records and other forms of information keep their legibility, reliability and integrity and can be accessed as long as needed subject to security and privacy provisions." Interoperability Dimension: Structural IoP Viewpoint: Interoperability Privacy viewpoint Additional identifier: http://data.europa.eu/dr8/DataManagementApplicationComponent EIF Layer: TechnicalApplication Definition: Data Analytics ABB is an Application Component that enables the implementation of procedures to analyze data and extract insights that can be used to improve business decision-making, optimize business processes, and drive innovation Source: Inspired in Data Act Source reference: https://digital-strategy.ec.europa.eu/en/policies/data-act Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/DataAnalyticsApplicationComponent LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:DataAnalyticsApplicationComponent Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Microsoft Power BI - Power BI is a business analytics service by Microsoft. It aims to provide interactive visualizations and business intelligence capabilities with an interface simple enough for end users to create their own reports and dashboards. It is part of the Microsoft Power Platform.(https://powerbi.microsoft.com/it-it/what-is-power-bi/) eira:iopSaliency: The Data Analytics Component ABB  is salient for technical interoperability because it provides the implementation of functionalities for the automation of mechanical processes and algorithms that work over raw data for human consumption. Additional information: Data analytics component enable the automation of mechanical processes and algorithms that work over raw data for human consumption. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/DataAnalyticsApplicationComponent EIF Layer: TechnicalApplication DESCRIPTION: A Client request for service ABB is an application event abb that refers to the moment in which a user perform a request through a computer hardware or software device to have access to a service provided by a server. SOURCE: https://www.techtarget.com/searchenterprisedesktop/definition/client Definition: Machine Request for Service ABB is an Application Event that represents an application state change made by a digital system for assistance or support from a service provider Source: Inspired in Archimate Source reference: https://pubs.opengroup.org/architecture/archimate3-doc/chap09.html Identifier: http://data.europa.eu/dr8/ClientrequestforserviceApplicationEvent eira:ID: ABB584 ABB name: eira:ClientrequestforserviceApplicationEvent Definition: Machine to Machine Interface ABB is an Application Interface that enables the exchange of data between a service and other services. This ABB is a key interoperability enabler (*) for assessing compatible interfaces. Source: EIA Action (*)DECISION (EU) 2015/2240 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 25 November 2015 establishing a programme on interoperability solutions and common frameworks for European public administrations, businesses and citizens (ISA2 programme) as a means for modernising the public sector. Source reference: https://ec.europa.eu/isa2/eif_en Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/MachineToMachineInterfaceApplicationInterface LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:MachineToMachineInterfaceApplicationInterface Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): XMLGate TRACES Businesses (XTB) - Webservices enabling the management of organisations and cities registered in TRACES. https://circabc.europa.eu/sd/a/dc77e52b-dfba-4dcc-aa39-6a54748db01d/XmlGate%20TRACES%20Businesses%20Manual.doc. Interoperability Saliency: The Machine to Machine Interface ABB is a key interoperability enabler because it supports to achieve technical behavioral interoperability by enabling the exchange of data, information, and knowledge between digital public services as stated in the EIF recommendation n°5: ""Ensure internal visibility and provide external interfaces for European public services" and recommendation n°9:"Ensure data portability, namely that data is easily transferable between systems and applications supporting the implementation and evolution of European public services without unjustified restrictions, if legally possible." Interoperability Dimension: Behavioral IoP Viewpoint: Interoperability Security viewpoint Additional identifier: http://data.europa.eu/dr8/MachineToMachineInterfaceApplicationInterface EIF Layer: TechnicalApplication Definition: Web Service ABB is an Application Interface that enables interoperability between different applications or systems over the Internet Source: W3C Source reference: https://www.w3.org/TR/2004/NOTE-ws-arch-20040211/#relwwwrest Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/WebServiceApplicationInterface LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:WebServiceApplicationInterface Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Web Services Description Language (WSDL) - WSDL is an XML format for describing network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information. The operations and messages are described abstractly, and then bound to a concrete network protocol and message format to define an endpoint. https://www.w3.org/TR/wsdl.html Interoperability Saliency: The Web Service Application Interface ABB is salient for interoperability because, from the beginning, Web services can be interoperable by design. By putting in place web services, interoperability can be guaranteed between systems and applications, and therefore, among digital public services. Interoperability Dimension: Behavioral IoP Additional identifier: http://data.europa.eu/dr8/WebServiceApplicationInterface EIF Layer: TechnicalApplication Definition: API ABB is an Application Interface that enables a set of rules and specifications that allow different software components or systems to communicate and exchange data Source: EPDB Source reference: http://api.epdb.eu/#:~:text=The%20API%20can%20help%20you%20conduct%20research%2C%20create,access%20to%20meta%20data%20on%20European%20Union%20legislation. Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/APIApplicationInterface LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:APIApplicationInterface Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): RapidAPI - RapidAPI is a collection of predefined APIs that are free to test, specifically updated for 2021. https://rapidapi.com/collection/list-of-free-apis Interoperability Saliency: API Application Interface ABB is a key interoperability enabler (*) for behavioural interoperability by enabling rules and specifications for data exchange between systems and digital public services components. Interoperability Dimension: Behavioral IoP Viewpoint: Key Interoperability Enablers viewpoint Additional identifier: http://data.europa.eu/dr8/APIApplicationInterface EIF Layer: TechnicalApplication Definition: Human Interface ABB is an Application Interface that enables the exchange of data between stakeholders (individuals, public administration or legal entities) and a service. This ABB is a key interoperability enabler (*) for assessing compatible interfaces. Source: EIA Action Source reference: https://ec.europa.eu/isa2/eif_en Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/HumanInterfaceApplicationInterface LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:HumanInterfaceApplicationInterface Synonym: User interface, UI, Graphical User Interface, GUI Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): GrapesJS - GrapesJS is an open-source, multi-purpose, Web Builder Framework which combines different tools and features with the goal to help you (or users of your application) to build HTML templates without any knowledge of coding. It's a perfect solution to replace the common WYSIWYG editors, which are good for content editing but inappropriate for creating HTML structures. You can see it in action with the official demos, but using its API you're able to build your own editors. https://grapesjs.com/ Interoperability Saliency: The Human Interface ABB is a key interoperability enabler because it supports to achieve technical behavioral interoperability by enabling the exchange of data, information, and knowledge between digital public services and individuals. Interoperability Dimension: Behavioral IoP Viewpoint: Interoperability Security viewpoint Additional identifier: http://data.europa.eu/dr8/HumanInterfaceApplicationInterface EIF Layer: TechnicalApplication Definition: Conformance Testing ABB is an Application Service that enables the activities and rules to determine whether a tool, platform or service faithfully meets the requirements of a standard or specification Source: NIST Source reference: https://www.nist.gov/itl/ssd/information-systems-group/conformance-testing Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/ConformanceTestingApplicationService LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:ConformanceTestingApplicationService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Interoperability Testbed - The Test Bed allows users to execute predefined test cases on their systems in order to test the conformance to standards and requirements, simulate a web-service, validate content and test a complete message exchange protocol. The Testbed manages test cases and users, and orchestrates domain-specific components, the domain-specific logic is in separate components that are used via web services. Test results are provided in a standardised, machine-readable format. The Test Bed also offers a test registry and repository (TRR) to store test artefacts (assertions, test cases, validation schemas, etc.) and compile test services (validation services, simulator services, etc.). Please visit the following website for more information: https://ec.europa.eu/isa2/solutions/interoperability-test-bed_en Interoperability Saliency: The Conformance Testing Services ABB  is salient for technical interoperability because it enables the validation and verification that several solutions at one or more layers of the interoperability stack and they satisfy certain interoperability requirements. Additional information: The logistics of interoperability testing is usually more costly (time, coordination, interoperability), and interoperability testing is no substitute for a conformance test suite. Experience shows that interoperability testing is more successful and less costly when conformance of implementations has been tested first. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/ConformanceTestingApplicationService EIF Layer: TechnicalApplication Definition: Orchestration Service ABB is an Application Service that enables the definition of the sequence and conditions in which one service invokes other services to realize some useful function. Source: W3C Source reference: https://www.w3.org/TR/ws-arch/ Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/OrchestrationApplicationService LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:OrchestrationApplicationService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Apache ODE - Apache ODE (Orchestration Director Engine) software executes business processes written following the WS-BPEL standard. It talks to web services, sending and receiving messages, handling data manipulation and error recovery as described by your process definition. It supports both long and short living process executions to orchestrate all the services that are part of your application. http://ode.apache.org/ Interoperability Saliency: The Orchestration Service ABB  is salient for technical interoperability because it provides the functionality of "automated" business processes coordination. The EIF's Conceptual model for integrated EU public services foresees the concept a Coordination for Integrated Service Delivery. The Model comprises an "integrated service delivery" is based on a "coordination function", which is related to SOA principles such as choreography and orchestration, to manage internal business processes in order to remove complexity for the end-user, as stated in the EIF: "The coordination function ensures that needs are identified and appropriate services are invoked and orchestrated to provide a European public service. This function should select the appropriate sources and services and integrate them. Coordination can be automated or manual." Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/OrchestrationApplicationService EIF Layer: TechnicalApplication Definition: e-Seal Creation ABB is an Application Service that enables to sign of data in electronic forms on behalf of a legal person Source: eIDAS - REGULATION (EU) No 910/2014 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 23 July 2014 on electronic identification and trust services for electronic transactions in the internal market and repealing Directive 1999/93/EC. Source reference: http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv%3AOJ.L_.2014.257.01.0073.01.ENG Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/E-SealCreationApplicationService LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:E-SealCreationApplicationService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): CEF eSignature DSS - DSS (Digital Signature Services) is an open-source software library for electronic signature creation and validation. DSS supports the creation and verification of interoperable and secure electronic signatures in line with European legislation. In particular, DSS aims to follow the eIDAS Regulation and related standards closely. DSS can be re-used in an IT solution for electronic signatures to ensure that signatures are created and verified in line with European legislation and standards. DSS allows re-use in a variety of different ways: in an applet, in a stand-alone application or in a server application. DSS can also be used as a reference implementation for IT solutions which do not directly re-use it. CEF eSignature's DSS open-source library delivers the following benefits to its users: • Open-source software under LGPL 2.1, a non-viral open source license; • Interoperability of the e-signatures; • Supports both e-signatures and e-seals; • Validation of countersignatures and multiple signatures; • Alignment with the eIDAS Regulation and related standards; • Supports EU standards on: o Signature formats and packaging methods; o Signature validation procedures; • Validation relying on Member States' trusted lists: o Status of trust service providers/trust service, compensation of information, path validation. https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/eSignaturefile:///C:/Users/bocquilp/Downloads/DSS(ServiceOfferingDescription)%20(v0.03)%20(5).pdf Interoperability Saliency: The e-Seal Creation Service ABB  is salient for technical interoperability because it provides the functionalities required for e-seal creation service. Additional information: An ‘electronic seal' means data in electronic form, which is attached to or logically associated with other data in electronic form to ensure the latter’s origin and integrity. The ‘creator of a seal’ is a legal person who creates an electronic seal. Interoperability Dimension: Structural IoP Viewpoint: Interoperability Security viewpoint Additional identifier: http://data.europa.eu/dr8/E-SealCreationApplicationService EIF Layer: TechnicalApplication Definition: Audit ABB is an Application Service that enables the implementation of comprehensive procedural services capable of receiving inputs from different building blocks to ensure their correct behaviour, security or compliance with standards, regulations and best practices. Source: Inspired in SIMPL Source reference: https://digital-strategy.ec.europa.eu/en/news/simpl-cloud-edge-federations-and-data-spaces-made-simple Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/AuditApplicationService LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:AuditApplicationService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): OpenIAM audit service - OpenIAM Auditing Service ensures that detailed information about events and activities associated with identities or resources are logged into a centralized repository and be tracked. It offers the following features: • Sign-on, Sign-off, • User: create, update, delete or disable accounts, • Role: create, update, delete or disable accounts, • Resource: create, update, delete or disable accounts, • Password changes, resets, challenge response questions changes, • Synchronization events, • Reconciliation events. Several reporting templates are provided for a BIRT report writer for use in an Eclipse designer. Organizations can also generate their own reports in BIRT with SQL. https://www.openiam.com/products/identity-manager/features/audit-compliance/ Interoperability Saliency: The Audit Service ABB  is salient for technical interoperability because it defines the elements of an information system which need to be traced, for example to assure traceability of user actions as stated in the EIF: "Public administrations should ensure that a 'data access and authorisation plan’ which determines who has access to what data and under what conditions, to ensure privacy. Unauthorised access and security breaches should be monitored and appropriate actions should be taken to prevent any recurrence of breaches" Interoperability Dimension: Structural IoP Viewpoint: Interoperability Security viewpoint Additional identifier: http://data.europa.eu/dr8/AuditApplicationService EIF Layer: TechnicalApplication Definition: Agenda Management Service ABB is an Application Service that enables the procedures to create, distribute and manage events and meetings for public administration and services Source: Inspired in Public Works and Goverment Services Canada Source reference: https://buyandsell.gc.ca/cds/public/2016/11/23/c7b27e0ac41ad50ffae2f12b0a837875/ABES.PROD.PW_PWZ.B014.E10051.ATTA001.PDF Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/AgendaManagementApplicationService LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:AgendaManagementApplicationService Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Innovation Public Procurement Broker (IPPB). https://ec.europa.eu/futurium/en/system/files/ged/action_7_innovation_public_procurement_broker_guideline.pdf Interoperability Saliency: The Agenda Management Application Service ABB is salient for technical interoperability because it allows managing and orchestrating different events physical and digital ones within a determined workflow according to the delivery model of each digital public service. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/AgendaManagementApplicationService EIF Layer: TechnicalApplication Definition: Request Validation ABB is an Application Service that enables the process of verifying that the data sent to a web server from a client is safe and meets the expected format and standards. Source: Inspired in CORS Source reference: https://ec.europa.eu/eurostat/cros/content/validation-levels_en Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/RequestValidationApplicationService LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:RequestValidationApplicationService Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): HORIZON 2020 Organisation's validation service https://ec.europa.eu/research/participants/docs/h2020-funding-guide/grants/applying-for-funding/register-an-organisation/validation-of-organisation_en.htm Interoperability Saliency: The Request Validation Application Service ABB is salient for interoperability because as a web service, it can ensure and validate if exchanged data is secured and meets the standards and specifications required. The validation can play a relevant role to ensure the health of systems and services and also the quality of information being exchanged between interoperable services. Interoperability Dimension: Structural IoP Viewpoint: Interoperability Security viewpoint Additional identifier: http://data.europa.eu/dr8/RequestValidationApplicationService EIF Layer: TechnicalApplication Definition: Privacy ABB is an Application Service enabling the share of functionalities such as storing, securing, anonymising, pseudonymising, rectifying and erasing personal data. Source: ePrivacy Regulation Source reference: https://digital-strategy.ec.europa.eu/en/policies/eprivacy-regulation Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/PrivacyApplicationService LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:PrivacyApplicationService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): SOLVIT - Solvit is a mailbox service for the access, rectification or deletion of personal data.(http://ec.europa.eu/solvit/privacy-statement/#maincontentSec8) Interoperability Saliency: The Privacy Service ABB  is salient for interoperability because "security and privacy are primary concerns in the provision of public services" (EIF) and, as stated in EIF Recommendation 15: "Define a common security and privacy framework and establish processes for public services to ensure secure and trustworthy data exchange between public administrations and in interactions with citizens and businesses." Interoperability Dimension: Structural IoP Viewpoint: Interoperability Privacy viewpoint Additional identifier: http://data.europa.eu/dr8/PrivacyApplicationService EIF Layer: TechnicalApplication Definition: Data Space Connector Consumer ABB is an Application Service that enables data gathering and accessibility over available data sources and data in terms of content, structure quality, actuality and other attributes. Source: IDSA Source reference: https://internationaldataspaces.org/offers/ids-components/ Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/DataSpaceConnectorConsumerApplicationService LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:DataSpaceConnectorConsumerApplicationService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): The Dataspace Connector from the International Data Spaces Association. https://international-data-spaces-association.github.io/DataspaceConnector/ Interoperability Saliency: The Data Space Connector Consumer Application Service ABB is salient for technical interoperability because is the service that discovers and gather source for retrieving data. It is not just data, but the data space connector consumer service checks different characteristics and attributes from data such as content, and quality of the structure amongst others. This can be a clear and relevant role in the achievement of interoperability. Interoperability Dimension: Behavioral IoP Additional identifier: http://data.europa.eu/dr8/DataSpaceConnectorConsumerApplicationService EIF Layer: TechnicalApplication Definition: Digital Solution ABB is an Application Service that enables the implementation of public digital services or exposes an application behaviour. Source: Inspired in EIF Source reference: https://ec.europa.eu/isa2/sites/default/files/eif_brochure_final.pdf Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): EU Login - EU Login is the European Commission's user authentication service. It allows authorised users to access a wide range of Commission web services and websites, using a single email address and password. EU Login implements the single sign-on functionality. https://webgate.ec.europa.eu/cas/help.html IoP Dimension: Behavioral IoP LOST view: Technical view - application Interoperability saliency: The Digital Solution Service ABB is salient for technical interoperability because it is a central element the EIF's conceptual model for integrated public services. it represents the generalisation of all application services provided by an Interoperable European Solutionas as stated in the EIF: "Technical interoperability the applications and infrastructures linking systems and services." Identifier: http://data.europa.eu/dr8/DigitalSolutionApplicationService eira:ID: ABB441 ABB name: eira:DigitalSolutionApplicationService EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2022-18-01 Definition: Content Management ABB is an Application Service to enable the procedures to create, manage, and publish digital content, such as text, images, videos, and documents Source: EUI Source reference: https://www.eui.eu/ServicesAndAdmin/CommunicationsService/WebUnit/Web-CMS Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/ContentManagementApplicationService LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:ContentManagementApplicationService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): FPFIS-CMS: "The European Commission announced in the Commission Internet strategy plans to transform the EUROPA web site from a source of one-way information into a tool for communication and interaction (i.e. provide modern interactive web sites for the citizens and stakeholders). Web sites are a key tool for external communications. They are the institution's business card. Websites are a very cost-effective and efficient means of communication. EUROPA now hosts over 460 websites. EUROPA would benefit from fewer and better sites to respond to user needs. To address the shortcomings, as part of the Commission's IT governance process, the College on 30 November 2011, instructed Commission departments to rationalise the Institution's web presence. Reduce the cost (human, financial, technical) of the Commission's web presence via exploiting economies of scale and eliminating redundancies by building corporate solutions. The European Commission should offer a corporate service which optimizes and harmonizes the use of different website tools, which speeds up the creation of new external dynamic and social websites (i.e. in days or weeks and not months) and which provides a common solid modern shared infrastructure to support the rapid deployment of these sites". https://webgate.ec.europa.eu/fpfis/mwikis/thinktank/index.php/Content_Management_System_of_the_Flexible_Platform Interoperability Saliency: The Content Management Service ABB  is salient for technical interoperability because it provides and shares the functionalities of dynamic creation, distribution and analysis of contents (images, videos, etc.) as stated in the EIF: " Catalogues help others to find reusable resources (e.g. services, data, software, data models). Various types of catalogue exist, e.g. directories of services, libraries of software components, open data portals, registries of base registries, metadata catalogues, catalogues of standards, specifications and guidelines. Commonly agreed descriptions of the services, data, registries and interoperable solutions published in catalogues are needed to enable interoperability between catalogues." Additional information: Content Management ABB is an Application Service being responsible for: - developing Website templates and functionalities; - assigning appropriate user permissions and workflows; - providing trainings to the web working group; - developing tools and web controls to speed up and facilitate the work of the web working group; - giving support and advice to the web working group; - ensuring continuity of service and performance; - ensuring security and accessibility on the website; - ensuring disaster recovery processes and backup procedures; - setting up the website information architecture within the CMS; - setting up alert procedures and analytics on usage of the platform. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/ContentManagementApplicationService EIF Layer: TechnicalApplication Definition: Forms Management ABB is an Application Service that enables the procedures for i) dynamic creation, ii) distribution and ii) analysis of forms and online surveys. Source: ISA2 - EIA Action Source reference: https://joinup.ec.europa.eu/taxonomy/term/http_e_f_fdata_ceuropa_ceu_fdr8_fFormsManagementComponent Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/FormsManagementApplicationService LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:FormsManagementApplicationService Synonym: e-Forms Service Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): EACEA e-Forms - Electronic Application Forms - eForms: This page contains the resources and information required by applicants who wish to complete and submit an electronic application form (eForm) for a funding opportunity or for an accreditation. The programmes and actions are listed for which electronic application forms are currently available. The Application eForm homepage is where applicants for funding and applicants for accreditation must follow a series of steps in order to create their new application. https://eacea.ec.europa.eu/about-eacea/electronic-application-forms-eforms_en Interoperability Saliency: The Forms Management Service ABB  is salient for technical interoperability because it provides and shares the functionalities of dynamic creation, distribution and analysis of forms and online surveys as stated in the EIF: " Catalogues help others to find reusable resources (e.g. services, data, software, data models). Various types of catalogue exist, e.g. directories of services, libraries of software components, open data portals, registries of base registries, metadata catalogues, catalogues of standards, specifications and guidelines. Commonly agreed descriptions of the services, data, registries and interoperable solutions published in catalogues are needed to enable interoperability between catalogues." Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/FormsManagementApplicationService EIF Layer: TechnicalApplication Definition: Data Virtualization ABB is an Application Service that enables the access and manipulation of data from various sources without the need for physical data integration. Source: Joinup Source reference: https://joinup.ec.europa.eu/sites/default/files/inline-files/Data%20visualisation%20service%20definition.pdf Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/DataVirtualizationApplicationService LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:DataVirtualizationApplicationService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Virtuoso. Virtuoso Universal Server is modern platform built on existing open standards that harnesses the power of Hyperlinks (functioning as Super Keys) for breaking down data silos that impede both user and enterprise ability. For example, Virtuoso's core SQL & SPARQL powers many Enterprise Knowledge Graph initiatives just as it does DBpedia and a majority of nodes in the Linked Open Data Cloud -- the world's largest publicly accessible Knowledge Graph. https://big-data-test-infrastructure.ec.europa.eu/service-offering/virtuoso_en Interoperability Saliency: The Data Virtualization Application Service ABB is salient for technical interoperability because provides the tools for visualising datasets in a graphical way. These services can enable to visualise data and information from different sources, and public services, in a manner that can be better processed, understood, and therefore, interoperability can be achieved. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/DataVirtualizationApplicationService EIF Layer: TechnicalApplication Definition: Data Management ABB is an Application Service that enables the implementation of procedures to manage data effectively. These procedures include the collection, storage, organisation, maintenance, and usage of data resources, reliability and accessibility Source: Inspired in the Data Act Source reference: https://digital-strategy.ec.europa.eu/en/policies/data-act Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/DataManagementApplicationService LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:DataManagementApplicationService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Oracle Data Exchange - The Data Exchange Service provides several access points to the Event Repository, allowing the user to perform queries on these events: - The Query Subscription Administration Console configures the Data Exchange Service to create queries and periodically deliver query results to designated receivers (HTTP, JMS, and AS2). The Console can also test queries before subscribing, displaying user-readable events in XML format; - A SOAP Web service allows programmatic queries. This SOAP service is based on the technically complete, but not formally ratified as of October 2006, EPCglobal EPC Information Services (EPCIS) Version 1.0 Specification.EPCglobal EPCIS 1.0 Working Draft. https://docs.oracle.com/cd/E13197_01/rfid/enterprise_server/docs20/epcis/data-exchange.html Interoperability Saliency: The Data Management Service ABB  is salient for technical interoperability because it provides and shares the functionality for the share of data: "Legislation requires that decisions and data are stored and can be accessed for a specified time. This means that records and information in electronic form held by public administrations for the purpose of documenting procedures and decisions must be preserved and be converted, where necessary, to new media when old media become obsolete. The goal is to ensure that records and other forms of information keep their legibility, reliability and integrity and can be accessed as long as needed subject to security and privacy provisions." Interoperability Dimension: Structural IoP Viewpoint: Interoperability Privacy viewpoint Additional identifier: http://data.europa.eu/dr8/DataManagementApplicationService EIF Layer: TechnicalApplication Definition: Data Extraction, Transformation, and Loading ABB is an Application Service that enables the processes to extract data from various sources, transform the data to specific data models and load the data into a target data store. Source: Inspired in definitions from referent companies of IT sector Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/DataExtractionTransformationAndLoadingApplicationService LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:DataExtractionTransformationAndLoadingApplicationService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Eurostat transformation service - The transformation service allows datasets to be converted from one file format to another, optionally performing additional tasks, such as mapping and transcoding. The service is operational but is currently only available for internal consumption within Eurostat. However, the source code of both web service and software component is available in the SDMX webspace: http://ec.europa.eu/eurostat/web/sdmx-infospace/validation-transformation/transformation-services Interoperability Saliency: The Data Extraction, Transformation, and Loading Service ABB  is salient for technical interoperability because it provides the functionalities to transform internal data structures to common and agreed interoperable formats as stated in the EIF recommendation n° 41: "Establish procedures and processes to integrate the opening of data in your common business processes, working routines, and in the development of new information systems." Interoperability Dimension: Structural IoP Viewpoint: Interoperability Privacy viewpoint Additional identifier: http://data.europa.eu/dr8/DataExtractionTransformationAndLoadingApplicationService EIF Layer: TechnicalApplication Definition: Data Space Connector Provider ABB is an Application Service that enables maintenance control over the data and sets the conditions for its use in the data space ecosystem. Source: IDSA Source reference: https://internationaldataspaces.org/offers/ids-components/ Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/DataSpaceConnectorProviderApplicationService LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:DataSpaceConnectorProviderApplicationService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): The Dataspace Connector from the International Data Spaces Association. https://international-data-spaces-association.github.io/DataspaceConnector/ Interoperability Saliency: The Data Space Connector Provider Application Service ABB is salient for technical interoperability because is a key element in the data spaces environment and interoperability, as this service sets the conditions for the consumption of data by other services or parties. Interoperability Dimension: Behavioral IoP Additional identifier: http://data.europa.eu/dr8/DataSpaceConnectorProviderApplicationService EIF Layer: TechnicalApplication Definition: Authorisation ABB is an Application Service that enables processes to formalise the electronic identification of a natural or legal person, or the origin and integrity of data in the electronic form to be confirmed Source: Joinup Source reference: https://joinup.ec.europa.eu/taxonomy/term/http_e_f_fdata_ceuropa_ceu_fdr8_fIdentityManagementService Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/AuthorisationApplicationService LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:AuthorisationApplicationService Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Users roles are managed and linked to EU Login accounts (https://ec.europa.eu/research/participants/docs/h2020-funding-guide/user-account-and-roles/roles-and-access-rights_en.htm). EU Login is the entry gate to sign in to different European Commission services and/or other systems. EU Login verifies your identity and allows recovering your personal settings, history and access rights in a secure way. You can sign in using social media accounts or the EU Login account. Interoperability Saliency: The Authorisation Application Service ABB is salient for interoperability because it represents the identifications of actors (natural or legal persons) involved in system interactions, ensuring that the service and the data contained are accessed by actors with granted permissions. Additionally, this can be used as part of the data integrity process to identify the origin of certain data. In general, authorisation services allow for the maintenance of control and integrity of the available data, ensuring its quality when exchanged. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/AuthorisationApplicationService EIF Layer: TechnicalApplication Definition: Data Persistence ABB is an application service that enables the procedures that allow data to be stored and retrieved over an extended period of time. Source: Inspired in European Comision Data Strategy Source reference: https://commission.europa.eu/strategy-and-policy/priorities-2019-2024/europe-fit-digital-age/european-data-strategy_en Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/DataPersistenceApplicationService LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:DataPersistenceApplicationService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Context Broker as a CEF Building Block. https://ec.europa.eu/digital-building-blocks/wikis/download/attachments/82773424/Context%20Broker%20Brochure.pdf?version=1&modificationDate=1558016168498&api=v2 Interoperability Saliency: The Data Persistence Application Service ABB is salient for technical interoperability because it implements the ability to retrieve and store data in a long-term approach. This is relevant for interoperability as it can extend the period in which data can be used, retrieved, and exchanged improving the quality and range of data that can be exchanged, and therefore, is a key element for digital public services interoperability. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/DataPersistenceApplicationService EIF Layer: TechnicalApplication Definition: e-Archiving ABB is an Application Service enabling the permanent or long-term storage of selected (by an authority) electronic documents or information for preservation purposes like their enduring research value and memory aid. Source: ISA2 - EIA Action Source reference: https://ec.europa.eu/isa2/actions/towards-european-interoperability-architecture_en/ Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/E-ArchivingApplicationService LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:E-ArchivingApplicationService Synonym: Preservation Service Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): CEF eArchiving: eArchiving provides the core specifications, software, training and knowledge to tackle the challenge of short, medium and long-term data management and reuse in a sustainable, authentic, cost-efficient, manageable and interoperable way. https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/eArchiving Interoperability Saliency: The e-Archiving Service ABB  is salient for technical interoperability because it provides and shares the functionality for the long-term or permanent preservation of records and information in electronic form in order to ensure their temporal egibility, reliability and integrity as stated in the EIF: "Legislation requires that decisions and data are stored and can be accessed for a specified time. This means that records and information in electronic form held by public administrations for the purpose of documenting procedures and decisions must be preserved and be converted, where necessary, to new media when old media become obsolete. The goal is to ensure that records and other forms of information keep their legibility, reliability and integrity and can be accessed as long as needed subject to security and privacy provisions." Additional information: The EIRA(c) differentiates between document management, record management and e-archiving as follows: - Document management is primarily about day-to-day use of electronic documents (create/update/delete/versioning) within the operational environment; - Record management is primarily about ensuring that information (e.g. in form of an electronic document or database record) is available for business and legal purposes (e.g. to proof and track the handling of contracts). If an electronic document or information is becoming a record (an authority declares it as a record) that electronic document or information needs to be handled by the record management service (based on specific business or legal reasons (e.g. contract negotiation)); - e-Archiving is primarily about storing records which have been selected (by an authority) for permanent or long-term preservation due to their enduring research value and as a memory aid. An electronic document or information which a) is managed by the document management service or the record management service and b) is no longer needed for business or legal purposes or day-to-day activities, and c) still has value for research purposes or as a memory aid, the electronic document should be managed by the e-archiving service”. Interoperability Dimension: Structural IoP Viewpoint: Interoperability Privacy viewpoint Additional identifier: http://data.europa.eu/dr8/E-ArchivingApplicationService EIF Layer: TechnicalApplication Definition: Integrity Verification ABB is an Application Service that enables the procedures to ensure that information has not been altered in an unauthorized manner since it was created, transmitted or stored. Source: CSRC Source reference: https://csrc.nist.gov/glossary/term/integrity_verification Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/IntegrityVerificationApplicationService LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:IntegrityVerificationApplicationService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): WITDOM’s Integrity and Consistency Verification component protects the integrity and consistency of data outsourced to an untrusted remote storage. https://www.cyberwatching.eu/projects/1006/witdom/products/witdom-integrity-and-consistency-verification Interoperability Saliency: The Integrity Verification Application Service ABB is salient for interoperability because is a key service to ensure data integrity, it can perform checks on: changes on the data, if changes are authorised or not, and when those changes have been performed. By ensuring this, digital public services can provide additional trust in the data and information provided to stakeholders. Interoperability Dimension: Structural IoP Viewpoint: Interoperability Security viewpoint Additional identifier: http://data.europa.eu/dr8/IntegrityVerificationApplicationService EIF Layer: TechnicalApplication Definition: Data space ABB is an Application Service as the virtual space that enables the creation of a single market for data by integrating, transforming and making available such data. Source: European Comision-Data Act Source reference: https://digital-strategy.ec.europa.eu/en/policies/strategy-data Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/DataSpaceApplicationService LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:DataSpaceApplicationService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Mobility Data Space, The Mobility Data Space goes back to a resolution of the Concerted Action Mobility (KAM) of Germany's Federal Government from November 2019. More than 200 German mobility stakeholders from the science, industry and public administration sectors worked on the concept. acatech - the National Academy of Science and Engineering steered and coordinated the process. https://mobility-dataspace.eu/ Interoperability Saliency: The Data Space Application Service ABB is salient for technical interoperability because it appears as a single space where different stakeholders can integrate, transform and make information available for interested parties to reuse. Interested parties can be individuals, components or services consuming or providing data to that single space. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/DataSpaceApplicationService EIF Layer: TechnicalApplication Definition: e-Seal Preservation ABB is an Application Service that enables the procedures to extend the trustworthiness of the qualified electronic signature beyond the technological validity period. Source: eIDAS - REGULATION (EU) No 910/2014 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 23 July 2014 on electronic identification and trust services for electronic transactions in the internal market and repealing Directive 1999/93/EC. Source reference: http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv%3AOJ.L_.2014.257.01.0073.01.ENG Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/E-SealPreservationApplicationService LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:E-SealPreservationApplicationService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): CEF eSignature DSS - DSS (Digital Signature Services) is an open-source software library for electronic signature creation and validation. DSS supports the creation and verification of interoperable and secure electronic signatures in line with European legislation. In particular, DSS aims to follow the eIDAS Regulation and related standards closely. DSS can be re-used in an IT solution for electronic signatures to ensure that signatures are created and verified in line with European legislation and standards. DSS allows re-use in a variety of different ways: in an applet, in a stand-alone application or in a server application. DSS can also be used as a reference implementation for IT solutions which do not directly re-use it. CEF eSignature's DSS open-source library delivers the following benefits to its users: • Open-source software under LGPL 2.1, a non-viral open source license; • Interoperability of the e-signatures; • Supports both e-signatures and e-seals; • Validation of countersignatures and multiple signatures; • Alignment with the eIDAS Regulation and related standards; • Supports EU standards on: o Signature formats and packaging methods; o Signature validation procedures; • Validation relying on Member States' trusted lists: o Status of trust service providers/trust service, compensation of information, path validation. https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/eSignaturefile:///C:/Users/bocquilp/Downloads/DSS(ServiceOfferingDescription)%20(v0.03)%20(5).pdf Interoperability Saliency: The e-Seal Preservation Service ABB  is salient for technical interoperability because it provides the functionalities required for e-seal preservation service. Additional information: An ‘electronic seal' means data in electronic form, which is attached to or logically associated with other data in electronic form to ensure the latter’s origin and integrity. The ‘creator of a seal’ is a legal person who creates an electronic seal. Interoperability Dimension: Structural IoP Viewpoint: Interoperability Security viewpoint Additional identifier: http://data.europa.eu/dr8/E-SealPreservationApplicationService EIF Layer: TechnicalApplication Definition: e-Timestamp Creation ABB is an Application Service that enables the recording of the date and time when a specific electronic document, data or transaction is created or modified. This ABB verifies the existence, integrity, and authenticity of an electronic document, data or transaction. Source: eIDAS - REGULATION (EU) No 910/2014 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 23 July 2014 on electronic identification and trust services for electronic transactions in the internal market and repealing Directive 1999/93/EC. Source reference: http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv%3AOJ.L_.2014.257.01.0073.01.ENG Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/E-TimestampCreationApplicationService LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:E-TimestampCreationApplicationService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): DigiStamp eTimeStamp® - DigiStamp eTimeStamp® protects the intellectual property in any computer file: • Use Desktop and Web applications for on-demand protection; • Plug the Timestamp Authority into the automated systems. Plug-in rigorous implementation of US & EU standards: • Secure, reliable, RFC 3161 timestamp cloud service; • Archiving and Hash Chaining keyless security; • Elliptic Curve Upgrade; Implementation of the Internet Engineering Task Force's RFC 3161 means DigiStamp timestamps are understood by data validation systems the world over: • Implementation of ANSI X9.95 further increases the compatibility of our timestamps; • Compliance with IETF RFC 3628 gives credence to the trustworthiness of our Time Stamp Authorities.; • Conformance to IETF RFC 3126 makes our timestamps usable for long-term, legally binding agreements. https://www.digistamp.com/ Interoperability Saliency: The e-Timestamp Creation Service ABB  is salient for technical interoperability because it provides the functionalities required for e-Timestamp creation service. Additional information: An ‘electronic time stamp’ means data in electronic form which binds other data in electronic form to a particular time establishing evidence that the latter data existed at that time. Interoperability Dimension: Structural IoP Viewpoint: Interoperability Security viewpoint Additional identifier: http://data.europa.eu/dr8/E-TimestampCreationApplicationService EIF Layer: TechnicalApplication Definition: Authentication ABB is an Application Service that enables the functionality of grating users to access the platforms or the services. Source: eIDAS - REGULATION (EU) No 910/2014 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 23 July 2014 on electronic identification and trust services for electronic transactions in the internal market and repealing Directive 1999/93/EC. Source reference: http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv%3AOJ.L_.2014.257.01.0073.01.ENG Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/AuthenticationApplicationService LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:AuthenticationApplicationService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): EU Login - EU Login is the European Commission's user authentication service. It allows authorised users to access a wide range of Commission web services. EU Login is the entry gate to sign in to different European Commission services and/or other systems. EU Login verifies your identity and allows recovering your personal settings, history and access rights in a secure way. You can sign in using social media accounts or the EU Login account. EU Login supports a variety of verification methods: • Password; • ECAS Mobile App PIN code; • ECAS Mobile App QR code; • On mobile authentication; • Mobile phone + SMS; • Token and Token CRAM. https://webgate.ec.europa.eu/cas/about.html Interoperability Saliency: The Authentication Service ABB is salient for technical interoperability because it provides the functionalities of user authentication. Additional information: ‘Electronic identification’ means the process of using person identification data in electronic form uniquely representing either a natural or legal person, or a natural person representing a legal person; ‘Authentication’ means an electronic process that enables the electronic identification of a natural or legal person, or the origin and integrity of data in electronic form to be confirmed; Interoperability Dimension: Structural IoP Viewpoint: Interoperability Security viewpoint Additional identifier: http://data.europa.eu/dr8/AuthenticationApplicationService EIF Layer: TechnicalApplication Definition: Data Analytics ABB is an Application Service that enables the use of procedures to analyze data and extract insights that can be used to improve business decision-making, optimize business processes, and drive innovation Source: Inspired in Data Act Source reference: https://digital-strategy.ec.europa.eu/en/policies/data-act Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/DataAnalyticsApplicationService LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:DataAnalyticsApplicationService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Microsoft Power BI - Power BI is a business analytics service by Microsoft. It aims to provide interactive visualizations and business intelligence capabilities with an interface simple enough for end users to create their own reports and dashboards. It is part of the Microsoft Power Platform.(https://powerbi.microsoft.com/it-it/what-is-power-bi/) eira:iopSaliency: The Data Analytics Service ABB  is salient for technical interoperability because it enables the automated processing and analysis of different data source. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/DataAnalyticsApplicationService EIF Layer: TechnicalApplication Definition: Metadata Management ABB is an Application Service that enables functionalities for the i) creation, ii) storage, iii) categorisation and iv) retrieval of metadata. Source: DAMA Source reference: http://www.dama.org/ Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/MetadataManagementApplicationService LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:MetadataManagementApplicationService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Eurostat SDMX repository: The Euro SDMX Registry is Eurostat’s implementation of an SDMX registry to facilitate the exchange of statistical data and metadata by serving as a metadata repository. It stores the SDMX artefacts needed for the parties to access and interpret the content of the exchanged statistical data and metadata sets. http://ec.europa.eu/eurostat/web/sdmx-infospace/sdmx-it-tools/sdmx-registry Interoperability Saliency: The Metadata management Service ABB  is salient for interoperability because it provides and shares the functionalities to manage metadata. EIF recommends to prioritise it: "Put in place an information management strategy at the highest possible level to avoid fragmentation and duplication. Management of metadata, master data and reference data should be prioritised". Interoperability Dimension: Structural IoP Viewpoint: Interoperability Privacy viewpoint Additional identifier: http://data.europa.eu/dr8/MetadataManagementApplicationService EIF Layer: TechnicalApplication Definition: Schedule Management Service ABB is an Application Service that enables the procedures to manage time and events in the achievement of the goals and delivery of public services. Source: Inspired in Public Works and Goverment Services Canada Source reference: https://buyandsell.gc.ca/cds/public/2016/11/23/c7b27e0ac41ad50ffae2f12b0a837875/ABES.PROD.PW_PWZ.B014.E10051.ATTA001.PDF Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/ScheduleManagementApplicationService LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:ScheduleManagementApplicationService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Chronos is a replacement for cron. It is a distributed and fault-tolerant scheduler that runs on top of Apache Mesos that can be used for job orchestration. It supports custom Mesos executors as well as the default command executor. Thus by default, Chronos executes sh (on most systems bash) scripts. https://sourceforge.net/projects/chronos.mirror/ Interoperability Saliency: The Schedule Management Application Service ABB is salient for technical interoperability because it allows managing and orchestrating different events physical and digital ones within a determined workflow according to the delivery model of each digital public service. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/ScheduleManagementApplicationService EIF Layer: TechnicalApplication Definition: Data Quality ABB is an Application Service that enables the procedures to ensure the data is accurate, complete, consistent, and up-to-date Source: Eurostat Data Validation Source reference: http://ec.europa.eu/eurostat/data/data-validation Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/DataQualityApplicationService LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:DataQualityApplicationService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Eurostat Struval - The Structural Validation service (called STRUVAL) performs structural validation of statistical data files following the SDMX Information Model for a given data flow. It ensures that a data file respects the following key elements: • SDMX compliance in terms of checks on file format and completeness in terms of mandatory fields; • SDMX compliance in terms of the structure and coding defined by the Data Structure Definition (DSD); • The constraints defined for respective data flows. The STRUVAL service returns a response containing a machine-readable message that is processed by the process manager. The invoker of the service receives a validation report, regardless of the result of the process (in case of no failures the reports hold no records). http://ec.europa.eu/eurostat/web/sdmx-infospace/validation-transformation/structural-validation Interoperability Saliency: The Data Quality Service ABB  is salient for technical interoperability because it shares the functionality to validate if data received (or to be sent) is compliant with common and agreed interoperable formats as stated in the EIF recommendation n° 41: "Establish procedures and processes to integrate the opening of data in your common business processes, working routines, and in the development of new information systems." Interoperability Dimension: Structural IoP Viewpoint: Interoperability Privacy viewpoint Additional identifier: http://data.europa.eu/dr8/DataQualityApplicationService EIF Layer: TechnicalApplication Definition: Accounting ABB is an Application Service that enables the process of tracking and recording access to resources, facilities and information. Source: Inspired in Springer (Authentication, Authorization and Accounting article) Source reference: https://link.springer.com/chapter/10.1007/978-3-030-52829-4_14 Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/AccountingApplicationService LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:AccountingApplicationService Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): BASICAL system was developed by the General Administration Intervention Board to give computer support to operations and information in the basic model of the Accounting Information System for Local Governments, in compliance with Order EHA/404/2004, of 23 November, approving the Basic Local Accounting Model Regulations. https://administracionelectronica.gob.es/ctt/verPestanaGeneralAbstract.htm?idIniciativa=basical#.ZAISY3bMI2w Interoperability Saliency: The Accounting Application Service ABB is salient for interoperability because it can be a mechanism to track and control access to data, applications, and services. This can help to identify when unauthorised changes or accesses have been accepted and data in a digital public servicer has been compromised and whom is the actor involved. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/AccountingApplicationService EIF Layer: TechnicalApplication Definition: e-Signature Preservation ABB is an Application Service extending the trustworthiness of the qualified electronic signature beyond the technological validity period. Source: eIDAS - REGULATION (EU) No 910/2014 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 23 July 2014 on electronic identification and trust services for electronic transactions in the internal market and repealing Directive 1999/93/EC. Source reference: http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv%3AOJ.L_.2014.257.01.0073.01.ENG Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/E-SignaturePreservationApplicationService LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:E-SignaturePreservationApplicationService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Namirial Spa Long term archiving solution - Namirial is a Trust Service Provider, focused on addressing the fast growing market of Digital Transaction Management (DTM), which includes legally compliant electronic signatures, managing and tracking documents flows, conducting secure transactions and ensuring secure storage of data. It provides a long term archiving: • Protect and preserve all documents generated while performing digital business transactions; • Make those documents easily searchable; • Accredited for Long-Term Archiving/Digital Preservation Services; • SaaS, high-availability, multi-company solution built to archive large volumes of documents. https://www.xyzmo.com/digital-signature/e-signature-products Interoperability Saliency: The e-Signature Preservation Service ABB  is salient for technical interoperability because it provides the functionalities required for e-signature preservation service. Additional information: An ‘electronic signature’ means data in electronic form which is attached to or logically associated with other data in electronic form and which is used by the signatory to sign. Interoperability Dimension: Structural IoP Viewpoint: Interoperability Security viewpoint Additional identifier: http://data.europa.eu/dr8/E-SignaturePreservationApplicationService EIF Layer: TechnicalApplication Definition: API Discovery and Catalogue Service ABB is an Application Service that enables the discovery and/or maintenance of the API Catalogue ABB. Source: Inspired in Gartner Source reference: https://www.gartner.com/en/information-technology/glossary/application-programming-interface Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/APIDiscoveryAndCatalogueApplicationService LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:APIDiscoveryAndCatalogueApplicationService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): RapidAPI - RapidAPI is a collection of predefined APIs that are free to test, specifically updated for 2021. https://rapidapi.com/collection/list-of-free-apis Interoperability Saliency: API Discovery and Catalogue Application Service ABB is a key interoperability enabler (*) for structural and behavioural interoperability by enabling and maintaining API Catalogues for public administration services. This is a key aspect enabling interoperability as it contributes to the discovery of APIs through catalogues. Interoperability Dimension: Structural IoP Viewpoint: Key Interoperability Enablers viewpoint Additional identifier: http://data.europa.eu/dr8/APIDiscoveryAndCatalogueApplicationService EIF Layer: TechnicalApplication Definition: Machine Translation ABB is an Application Service that enables the procedures for automated translation of text, metadata and concept classes or nomenclatures Source: CEF Automated Translation Source reference: https://ec.europa.eu/digital-single-market/en/news/tools-and-resources-cef-automated-translation Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/MachineTranslationApplicationService LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:MachineTranslationApplicationService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): CEF Digital - eTranslation building block: eTranslation is a Connecting Europe Facility (CEF) building block provided by the European Commission (EC). eTranslation provides an online machine translation service.(https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/eTranslation) Interoperability Saliency: The Machine Translation Service ABB  is salient for technical interoperability because it enables cross-lingual functionality by providing automated translation of text, metadata and concept classes or nomenclatures as stated in the EIF recommendation n°16: "Use information systems and technical architectures that cater for multilingualism when establishing a European public service. Decide on the level of multilingualism support based on the needs of the expected users." Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/MachineTranslationApplicationService EIF Layer: TechnicalApplication Definition: Registration Service ABB is an Application Service that enables users to sign-up for a service, application or platform through unique personal identification data. Source: eIDAS - REGULATION (EU) No 910/2014 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 23 July 2014 on electronic identification and trust services for electronic transactions in the internal market and repealing Directive 1999/93/EC. Source reference: http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv%3AOJ.L_.2014.257.01.0073.01.ENG Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/RegistrationApplicationService LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:RegistrationApplicationService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): BE:Trusted - BE:Trusted list including information related to the qualified trust service providers which are supervised by the issuing Member State, together with information related to the qualified trust services provided by them, in accordance with the relevant provisions laid down in Regulation (EU) No 910/2014 of the European Parliament and of the Council of 23 July 2014 on electronic identification and trust services for electronic transactions in the internal market. https://tsl.belgium.be/archive/TSL-BE-2016-T3_vi5_sn27%20SPF%20Economie_signed.pdf Interoperability Saliency: The Registration Service ABB  is salient for technical interoperability because it provides the functionalities of the discovery of essential information about accredited service providers. Interoperability Dimension: Structural IoP Viewpoint: Interoperability Security viewpoint Additional identifier: http://data.europa.eu/dr8/RegistrationApplicationService EIF Layer: TechnicalApplication Definition: e-Signature Verification and Validation Service ABB is an Application Service that enables the process of verifying and confirming that an electronic signature or a seal is valid. Source: eIDAS - REGULATION (EU) No 910/2014 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 23 July 2014 on electronic identification and trust services for electronic transactions in the internal market and repealing Directive 1999/93/EC. Source reference: http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv%3AOJ.L_.2014.257.01.0073.01.ENG Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/E-SignatureVerificationAndValidationApplicationService LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:E-SignatureVerificationAndValidationApplicationService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): CEF eSignature DSS - DSS (Digital Signature Services) is an open-source software library for electronic signature creation and validation. DSS supports the creation and verification of interoperable and secure electronic signatures in line with European legislation. In particular, DSS aims to follow the eIDAS Regulation and related standards closely. DSS can be re-used in an IT solution for electronic signatures to ensure that signatures are created and verified in line with European legislation and standards. DSS allows re-use in a variety of different ways: in an applet, in a stand-alone application or in a server application. DSS can also be used as a reference implementation for IT solutions which do not directly re-use it. CEF eSignature's DSS open-source library delivers the following benefits to its users: • Open-source software under LGPL 2.1, a non-viral open source license; • Interoperability of the e-signatures; • Supports both e-signatures and e-seals; • Validation of countersignatures and multiple signatures; • Alignment with the eIDAS Regulation and related standards; • Supports EU standards on: o Signature formats and packaging methods; o Signature validation procedures; • Validation relying on Member States' trusted lists: o Status of trust service providers/trust service, compensation of information, path validation. https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/eSignaturefile:///C:/Users/bocquilp/Downloads/DSS(ServiceOfferingDescription)%20(v0.03)%20(5).pdf Interoperability Saliency: The e-Signature Verification and Validation Service ABB  is salient for technical interoperability because it provides the functionalities required for e-signature verification and validation service. Additional information: An ‘electronic signature’ means data in electronic form which is attached to or logically associated with other data in electronic form and which is used by the signatory to sign. ‘Validation’ means the process of verifying and confirming that an electronic signature or a seal is valid. Interoperability Dimension: Structural IoP Viewpoint: Interoperability Security viewpoint Additional identifier: http://data.europa.eu/dr8/E-SignatureVerificationAndValidationApplicationService EIF Layer: TechnicalApplication Definition: Public Administration Single Window Service ABB is an Application that enables the processes to submit information and documents with a single entry point to fulfil all regulatory requirements. Source: United Nations Source reference: https://tfig.unece.org/contents/single-window-concept.htm Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/PublicAdministrationSingleWindowApplicationService LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:PublicAdministrationSingleWindowApplicationService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Mi Carpeta Ciudadana Carpeta Ciudadana is a personal online space that facilitates your relationship with public administrations. https://carpetaciudadana.gob.es/carpeta/clave.htm Interoperability Saliency: The Public Administration Single Window Application Service ABB is salient for technical interoperability because it acts as a single entry point for the provision and exchange of data between stakeholders and public organisations. This can improve not only the user experience but interoperability due to the standardised methods for data sharing. Interoperability Dimension: Behavioral IoP Additional identifier: http://data.europa.eu/dr8/PublicAdministrationSingleWindowApplicationService EIF Layer: TechnicalApplication Definition: e-Seal Verification and Validation ABB is an Application Service that enables the functionality of the verification of documents that are signed electronically. Source: eIDAS - REGULATION (EU) No 910/2014 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 23 July 2014 on electronic identification and trust services for electronic transactions in the internal market and repealing Directive 1999/93/EC. Source reference: http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv%3AOJ.L_.2014.257.01.0073.01.ENG Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/E-SealVerificationAndValidationApplicationService LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:E-SealVerificationAndValidationApplicationService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): CEF eSignature DSS - DSS (Digital Signature Services) is an open-source software library for electronic signature creation and validation. DSS supports the creation and verification of interoperable and secure electronic signatures in line with European legislation. In particular, DSS aims to follow the eIDAS Regulation and related standards closely. DSS can be re-used in an IT solution for electronic signatures to ensure that signatures are created and verified in line with European legislation and standards. DSS allows re-use in a variety of different ways: in an applet, in a stand-alone application or in a server application. DSS can also be used as a reference implementation for IT solutions which do not directly re-use it. CEF eSignature's DSS open-source library delivers the following benefits to its users: • Open-source software under LGPL 2.1, a non-viral open source license; • Interoperability of the e-signatures; • Supports both e-signatures and e-seals; • Validation of countersignatures and multiple signatures; • Alignment with the eIDAS Regulation and related standards; • Supports EU standards on: o Signature formats and packaging methods; o Signature validation procedures; • Validation relying on Member States' trusted lists: o Status of trust service providers/trust service, compensation of information, path validation. https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/eSignaturefile:///C:/Users/bocquilp/Downloads/DSS(ServiceOfferingDescription)%20(v0.03)%20(5).pdf Interoperability Saliency: The e-Seal Verification and Validation Service ABB  is salient for technical interoperability because it provides the functionalities required for e-seal verification and validation service. Additional information: An ‘electronic seal' means data in electronic form, which is attached to or logically associated with other data in electronic form to ensure the latter’s origin and integrity. The ‘creator of a seal’ is a legal person who creates an electronic seal. Interoperability Dimension: Structural IoP Viewpoint: Interoperability Security viewpoint Additional identifier: http://data.europa.eu/dr8/E-SealVerificationAndValidationApplicationService EIF Layer: TechnicalApplication Definition: e-Timestamp Verification and Validation ABB is an Application Service that enables the verification of timestamps used for establishing evidence that a given piece of data existed at a given point in time. Source: eIDAS - REGULATION (EU) No 910/2014 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 23 July 2014 on electronic identification and trust services for electronic transactions in the internal market and repealing Directive 1999/93/EC. Source reference: http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv%3AOJ.L_.2014.257.01.0073.01.ENG Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/E-TimestampVerificationAndValidationApplicationService LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:E-TimestampVerificationAndValidationApplicationService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): OpenSSL timestamp verification - OpenSSL is an open-source tool that can be used to retrieve and verify digital timestamps. (https://wiki.openssl.org/index.php/Manual:Ts(1)) and https://www.digistamp.com/technical/software-alternatives/using-openssl-to-request-timestamps/ Interoperability Saliency: The e-Timestamp Verification and Validation Service ABB  is salient for technical interoperability because it provides the functionalities required for e-timestamp verification and validation service. Additional information: An ‘electronic time stamp’ means data in electronic form which binds other data in electronic form to a particular time establishing evidence that the latter data existed at that time. Interoperability Dimension: Structural IoP Viewpoint: Interoperability Security viewpoint Additional identifier: http://data.europa.eu/dr8/E-TimestampVerificationAndValidationApplicationService EIF Layer: TechnicalApplication Definition: Identity Management ABB is an Application Service that enables the set of processes, policies and technologies used to manage and secure digital entities of individuals, devices and applications. Source: Inspired in eIDAS Source reference: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32014R0910&from=EN Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/IdentityManagementApplicationService LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:IdentityManagementApplicationService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): EU Login - EU Login is the European Commission's user authentication service. It allows authorised users to access a wide range of Commission web services. EU Login is the entry gate to sign in to different European Commission services and/or other systems. EU Login verifies your identity and allows recovering your personal settings, history and access rights in a secure way. You can sign in using social media accounts or the EU Login account. EU Login supports a variety of verification methods: • Password; • ECAS Mobile App PIN code; • ECAS Mobile App QR code; • On mobile authentication; • Mobile phone + SMS; • Token and Token CRAM. https://webgate.ec.europa.eu/cas/manuals/EU_Login_Tutorial_1.1.pdf Interoperability Saliency: The Identity Management Application Service is salient for interoperability because it can help in the management of digital identities for individuals, devices and applications, ensuring and enabling that information on digital public services is available under the proper conditions and to the specific target. This can ensure and enhance the quality of data meant to be exchanged through interoperable systems, applications and digital public services. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/IdentityManagementApplicationService EIF Layer: TechnicalApplication Definition: Service Discovery and Registry ABB is an Application Service that enables the process of automatically locating network services within distributed digital systems. Source: Inspired in INSPIRE Source reference: https://inspire.ec.europa.eu/glossary/DiscoveryService Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/ServiceDiscoveryAndRegistryApplicationService LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:ServiceDiscoveryAndRegistryApplicationService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): ZooKeeper - ZooKeeper is a centralized service registry for maintaining configuration information, naming, providing distributed synchronization, and providing group services. All of these kinds of services are used in some form or another by distributed applications. Each time they are implemented there is a lot of work that goes into fixing the bugs and race conditions that are inevitable. Because of the difficulty of implementing these kinds of services, applications initially usually skimp on them, which make them brittle in the presence of change and difficult to manage. Even when done correctly, different implementations of these services lead to management complexity when the applications are deployed. https://zookeeper.apache.org/ Interoperability Saliency: Service Discovery and Registry Service ABB is a key interoperability enabler (*) for structural and behavioural interoperability by enabling access rights for data that is necessary for accessing public administration components to target fast and easy communication and data exchange. Interoperability Dimension: Structural IoP Viewpoint: Key Interoperability Enablers viewpoint Additional identifier: http://data.europa.eu/dr8/ServiceDiscoveryAndRegistryApplicationService EIF Layer: TechnicalApplication Definition: Digital Workplace ABB is an Application Service that enables the procedures to freely collaborate independently from the location and boundaries while maintaining high-security standards and increasing productivity and efficiency. Source: European Comission Source reference: https://ec.europa.eu/info/publications/digital-workplace-strategy_en Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/DigitalWorkplaceApplicationService LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:DigitalWorkplaceApplicationService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Set of IT tools used by European Commission officials, workers, etc. There is a new strategy put in place by the Commission to improve the work of the different roles involved. https://europa.eu/digitec/news/digital-workplace-european-commission/ Interoperability Saliency: The Digital Workplace Application Service ABB is a key interoperability enabler (*) for behavioural and technical interoperability by enabling components for free collaboration and accessibility to public services, maintaining high-security standards. Interoperability Dimension: Behavioral IoP Viewpoint: Key Interoperability Enablers viewpoint Additional identifier: http://data.europa.eu/dr8/DigitalWorkplaceApplicationService EIF Layer: TechnicalApplication Definition: Data Publication ABB is an Application Service that enables the processes of making data available through the adoption of discoverable, accessible, and reusable mechanisms. Source: ISA2 Source reference: https://ec.europa.eu/isa2/sites/default/files/docs/publications/isa2-actions-phase2_-_poc_-_wp1_specifications_en.pdf Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/DataPublicationApplicationService LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:DataPublicationApplicationService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): European Data Portal - The European Data Portal harvests the metadata of Public Sector Information available on public data portals across European countries. Information regarding the provision of data and the benefits of re-using data is also included. What is Open Data? - Open (Government) Data refers to the information collected, produced or paid for by the public bodies (also referred to as Public Sector Information) and made freely available for re-use for any purpose. The licence will specify the terms of use; - Public sector information is information held by the public sector. The Directive on the re-use of public sector information provides a common legal framework for a European market for government-held data. It is built around the key pillars of the internal market: free flow of data, transparency and fair competition. It is important to note that not all of the public sector information is Open Data. Within the Portal, sections are dedicated to: - Searching datasets: Categories have been established to structure the metadata harvested from the various countries. These categories follow the revision of the DCAT Application Profile and have been mapped against the Eurovoc Thesaurus; - Providing Data: This section gives an insight into understanding Open Data from the perspective of a data provider. In addition, instructions are offered for those who wish their data portal to be harvested by the European Data Portal; - Using Data: How Open Data is being used, as well as the economic benefits of Open Data are detailed in this section; - Training and Library: eLearning modules about Open Data as well as training guides and a knowledge base referencing publications around Open Data and featured projects; - Portals can be national, regional, local or domain specific. They cover the 28 EU Member States, EEA, countries involved in the EU's neighbourhood policy and Switzerland. https://www.europeandataportal.eu/ Interoperability Saliency: The Data Pubblication Service ABB  is salient for technical interoperability because it provides the functionalities to make public data freely available for use and reuse by others unless restriction aoply as stated in the EIF recommendation n.2: "Publish the data you own as open data unless certain restrictions apply." Interoperability Dimension: Structural IoP Viewpoint: Interoperability Privacy viewpoint Additional identifier: http://data.europa.eu/dr8/DataPublicationApplicationService EIF Layer: TechnicalApplication Definition: Blockchain ABB is an Application Service that enables secure, transparent, and immutable record-keeping and transaction processing shared by all participants in a network. Source: Inspired in European Comission-Blockchain Strategy Source reference: https://digital-strategy.ec.europa.eu/en/policies/blockchain-strategy Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/BlockchainApplicationService LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:BlockchainApplicationService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Fishcoin Project, is a project using Blockchain technologies for seafood traceability. https://fishcoin.co/ Interoperability Saliency: The Blockchain Application Service ABB is salient for interoperability because as a ledger technology application service can contribute to the trustability of digital public services. It can enable the register and list of irrevocable transactional data being exchanged between digital public services. To that extent, a blockchain service can be enhancing digital public services by establishing a mechanism to track data, and the process applied to it. Additional information: Specifically, Blockchain stores records that contain a time stamp and reference links to previous transactions. With this information, anyone with access rights can trace back a transactional event, at any point in its history, belonging to any participant. A blockchain is one architectural design of the broader concept of distributed ledgers. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/BlockchainApplicationService EIF Layer: TechnicalApplication Definition: Access Management ABB is an Application Service aimed to grant authorized users the right to use a service, while preventing access to non-authorized users Source: ITIL v3 Source reference: https://wiki.en.it-processmaps.com/index.php/Access_Management Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/AccessManagementApplicationService LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:AccessManagementApplicationService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Belgian Federal Public Service Policy and Support - Role Management service: The Role Management service gives access managers the possibility to manage roles. A role gives access to an online government application. Characteristics: • A federal access management platform for public e-gov applications; • Three separate contexts: Businesses, Officials and Independent; • Roles that can only be attributed by a specific group of managers for a specific application within one of the three contexts; • Two different security levels of the application depending on the sensitivity of the information: user name, password and token; and electronic identity card with associated PIN code; • Authentication when connecting to an application; • Support with the implementation of the service; • Support while the service is being used. Users: All public services and institutions that want a secure access management for their applications: federal public services and institutions; Communities and Regions; Provinces, municipalities and local public social welfare centres; businesses or persons implementing government contracts. Requirements: application with Fedict Service Desk and signing up to a user agreement.(http://www.fedict.belgium.be/en/identificatie_beveiliging/rollenbeheer) Interoperability Saliency: The Access Management Service ABB  is salient for technical interoperability because it provides the functionality of allowing user to make an authorized and trusted use of IT Services, data and other assets as stated in the EIF: "Public administrations should ensure that a 'data access and authorisation plan’ which determines who has access to what data and under what conditions, to ensure privacy. Unauthorised access and security breaches should be monitored and appropriate actions should be taken to prevent any recurrence of breaches" Additional information: Access management helps to protect the confidentiality, integrity and availability of assets by ensuring that only authorized users are able to access or modify the assets. Interoperability Dimension: Structural IoP Viewpoint: Interoperability Security viewpoint Additional identifier: http://data.europa.eu/dr8/AccessManagementApplicationService EIF Layer: TechnicalApplication Definition: Knowledge Discovery ABB is an Application Service that enables a highly complex process where a lot of data manipulation tools with different characteristics have to be used together to reach the goal of previously unknown, potentially useful information extraction. Source: Inspired in EUROSTAT Source reference: https://ec.europa.eu/eurostat/statistics-explained/index.php?title=Glossary:Knowledge-intensive_services_(KIS) Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/KnowledgeDiscoveryApplicationService LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:KnowledgeDiscoveryApplicationService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): CELLAR. Cellar metadata is stored in a knowledge graph, and more specifically in a triple store. A SPARQL interface is used to query the metadata. https://op.europa.eu/en/web/cellar/cellar-data/metadata/knowledge-graph Interoperability Saliency: The Knowledge Discovery Application Service ABB is salient for technical interoperability because it performs a series of complex processes that incorporate multiple data channels, formats and characteristics that are processed to extract relevant information to be used by other digital public services. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/KnowledgeDiscoveryApplicationService EIF Layer: TechnicalApplication Definition: Data Exchange ABB is an Application Service enabling the secure exchange of messages, records, forms and other kinds of data between different individuals, organizations or systems. This includes data routing, except endpoint discovery. Source: EIFv2 Source reference: http://ec.europa.eu/isa/documents/isa_annex_ii_eif_en.pdf Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/DataExchangeApplicationService LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:DataExchangeApplicationService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): XMLGate - XMLGate is a Web service application used to validate an XML instance against a well-defined schema. The XML flow is submitted either via a PDF form or by uploading the XML file.(https://webgate.ec.europa.eu/sanco-xmlgate/Login.jsp;jsessionid=2MPn_N5Wg9Dar4_W2-yVL_Xg-VlW3kn47PLVbNise9X5Kycx1yLI!-25226473) Interoperability Saliency: The Data Exchange Service ABB is a key interoperability enabler (*) for behavioural and technical interoperability because it provides secure and trustworthy data exchange between different ICT systems as stated in the EIF: "Define a common security and privacy framework and establish processes for public services to ensure secure and trustworthy data exchange between public administrations and in interactions with citizens and businesses." Interoperability Dimension: Behavioral IoP Viewpoint: Interoperability Security viewpoint Additional identifier: http://data.europa.eu/dr8/DataExchangeApplicationService EIF Layer: TechnicalApplication Definition: Firewall Service ABB is an Application Service representing an integrated collection of security measures designed to prevent unauthorized electronic access to a networked computer system. Source: Dictionary Source reference: https://www.dictionary.com/browse/firewall Identifier: http://data.europa.eu/dr8/FirewallApplicationService eira:ID: ABB528 ABB name: eira:FirewallApplicationService Definition: e-Signature Creation ABB is an Application Service that enables the process of signing data, in electronic form by a natural person Source: eIDAS - REGULATION (EU) No 910/2014 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 23 July 2014 on electronic identification and trust services for electronic transactions in the internal market and repealing Directive 1999/93/EC. Source reference: http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv%3AOJ.L_.2014.257.01.0073.01.ENG Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/E-SignatureCreationApplicationService LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:E-SignatureCreationApplicationService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): CEF eSignature DSS - DSS (Digital Signature Services) is an open-source software library for electronic signature creation and validation. DSS supports the creation and verification of interoperable and secure electronic signatures in line with European legislation. In particular, DSS aims to follow the eIDAS Regulation and related standards closely. DSS can be re-used in an IT solution for electronic signatures to ensure that signatures are created and verified in line with European legislation and standards. DSS allows re-use in a variety of different ways: in an applet, in a stand-alone application or in a server application. DSS can also be used as a reference implementation for IT solutions which do not directly re-use it. CEF eSignature's DSS open-source library delivers the following benefits to its users: • Open-source software under LGPL 2.1, a non-viral open source license; • Interoperability of the e-signatures; • Supports both e-signatures and e-seals; • Validation of countersignatures and multiple signatures; • Alignment with the eIDAS Regulation and related standards; • Supports EU standards on: o Signature formats and packaging methods; o Signature validation procedures; • Validation relying on Member States' trusted lists: o Status of trust service providers/trust service, compensation of information, path validation. https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/eSignaturefile:///C:/Users/bocquilp/Downloads/DSS(ServiceOfferingDescription)%20(v0.03)%20(5).pdf Interoperability Saliency: The e-Signature Creation Service ABB  is salient for technical interoperability because it provides the functionalities required for e-signature creation service. Additional information: An ‘electronic signature’ means data in electronic form which is attached to or logically associated with other data in electronic form and which is used by the signatory to sign. Interoperability Dimension: Structural IoP Viewpoint: Interoperability Security viewpoint Additional identifier: http://data.europa.eu/dr8/E-SignatureCreationApplicationService EIF Layer: TechnicalApplication Definition: API Manager Service ABB is a Application Service that that enables organizations to manage their Application Programming Interfaces (APIs) and create new APIs easily Source: Gartner Source reference: https://www.gartner.com/en/information-technology/glossary/api-management Identifier: http://data.europa.eu/dr8/APIManagerApplicationService ABB name: eira:APIManagerApplicationService Definition: Artificial Intelligence ABB is an Application Service that enables the procedures to display intelligent behaviour by analysing their environment and taking actions with some degree of autonomy to achieve specific objectives. Source: European Comision Source reference: https://digital-strategy.ec.europa.eu/en/library/definition-artificial-intelligence-main-capabilities-and-scientific-disciplines Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/ArtificialIntelligenceApplicationService LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:ArtificialIntelligenceApplicationService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): PyTorch is a machine learning framework based on the Torch library, used for applications such as computer vision and natural language processing, originally developed by Meta AI and now part of the Linux Foundation umbrella. It is free and open-source software released under the modified BSD license. Although the Python interface is more polished and the primary focus of development, PyTorch also has a C++ interface. https://pytorch.org/ Interoperability Saliency: The Artificial Intelligence Application Service ABB is salient for technical interoperability because it refers to applications services that are able to analyse data, analysing the environment to take some automated actions for reaching objectives. Those services can enable digital public services to interact between them, exchanging data, and promoting interoperability of services. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/ArtificialIntelligenceApplicationService EIF Layer: TechnicalApplication Definition: Data Space Connector ABB is an Application Service that enables the easy and trustworthy procedure to share data and work collaboratively with other research institutions. Source: IDSA Source reference: https://international-data-spaces-association.github.io/DataspaceConnector/ Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/DataSpaceConnectorApplicationService LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:DataSpaceConnectorApplicationService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): The Dataspace Connector from the International Data Spaces Association. https://international-data-spaces-association.github.io/DataspaceConnector/ Interoperability Saliency: The Data Space Connector Application Service ABB is salient for technical interoperability because it provides the way or method, the procedure for different parties (public services, public organisations, etc) to exchange data in a collaborative method. Interoperability Dimension: Behavioral IoP Additional identifier: http://data.europa.eu/dr8/DataSpaceConnectorApplicationService EIF Layer: TechnicalApplication Definition: Registered Electronic Delivery ABB is an Application Service that enables the procedures to transmit sensitive or confidential documents and messages between parties. Source: eIDAS - REGULATION (EU) No 910/2014 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 23 July 2014 on electronic identification and trust services for electronic transactions in the internal market and repealing Directive 1999/93/EC. Source reference: http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv%3AOJ.L_.2014.257.01.0073.01.ENG Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/RegisteredElectronicDeliveryApplicationService LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:RegisteredElectronicDeliveryApplicationService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Qualified electronic registered delivery services listed with CEF Trusted List Browser tool Qualified electronic registered delivery services are listed on https://webgate.ec.europa.eu/tl-browser/#/search/1 and https://webgate.ec.europa.eu/tl-browser/#/search/1 Interoperability Saliency: The Registered Electronic Delivery Service ABB  is salient for technical interoperability because it provides the functionalities related to the handling of data transmission. Additional information: A registered Electronic Delivery shares functionalities that i) makes it possible to transmit data between third parties by electronic means and ii) provides evidence relating to the handling of the transmitted data, including proof of sending and receiving the data, and iii) that protects transmitted data against the risk of loss, theft, damage or any unauthorised alterations; Interoperability Dimension: Structural IoP Viewpoint: Interoperability Security viewpoint Additional identifier: http://data.europa.eu/dr8/RegisteredElectronicDeliveryApplicationService EIF Layer: TechnicalApplication Definition: Service Registry ABB is a Data Object that enables the implementation of a central repository of information that contains metadata about the available digital services. Source: Redhat Source reference: https://www.redhat.com/en/topics/integration/what-is-a-service-registry Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/ServiceRegistryDataObject LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:ServiceRegistryDataObject Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): ZooKeeper - ZooKeeper is a centralized service registry for maintaining configuration information, naming, providing distributed synchronization, and providing group services. All of these kinds of services are used in some form or another by distributed applications. Each time they are implemented there is a lot of work that goes into fixing the bugs and race conditions that are inevitable. Because of the difficulty of implementing these kinds of services, applications initially usually skimp on them, which make them brittle in the presence of change and difficult to manage. Even when done correctly, different implementations of these services lead to management complexity when the applications are deployed. https://zookeeper.apache.org/ Interoperability Saliency: The Service Registry ABB is a key interoperability enabler because it provides access to software systems over the Internet using standard protocols. In the most basic scenario there is a Web Service Provider that publishes a service and a Web Service Consumer that uses this service. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/ServiceRegistryDataObject EIF Layer: TechnicalApplication Definition: Base Registry ABB is a Data Object that refers to reliable sources of basic information that permits an efficient, secure, and transarent exchange of the data. Source: EIF Source reference: https://eur-lex.europa.eu/resource.html?uri=cellar:2c2f2554-0faf-11e7-8a35-01aa75ed71a1.0017.02/DOC_3&format=PDF Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/BaseRegistryDataObject LOST view: Semantic view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:BaseRegistryDataObject Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Business Registry - Registradores de España https://sede.registradores.org/site/mercantil?lang=en_EN Interoperability Saliency: The Base Registry Data Object ABB is salient for semantic interoperability because it provides a mechanism or method to ensure reliability of data, fostering secure data exchanges between public administrations and digital public services delivery. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/BaseRegistryDataObject EIF Layer: Semantic Definition: Master Data ABB is a Data Object that enables the implementation of non-transactional information to play a key role in the core operation of a business in public administrations and re-used for multiple purposes Source: European Medicines Agency Source reference: https://www.ema.europa.eu/en/glossary/master-data#:~:text=Master%20data%20Any%20non-transactional%20information%20considered%20to%20play,product%2C%20organisation%20and%20referential%20%28SPOR%29%20master%20data%20%27. Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/MasterDataDataObject LOST view: Semantic view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:MasterDataDataObject Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): EU-ERS: Master Data Register. https://circabc.europa.eu/ui/group/3cc8c417-0f2a-4eb4-8ff7-10d60638446a/information Interoperability Saliency: The Master Data ABB is a key interoperable enabler for semantic interoperability because it is a core element for digital public services enabling the reuse of relevant data such as identifiers for parties, or locations. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/MasterDataDataObject EIF Layer: Semantic Definition: Solution Specification ABB is a Data Object that refers to detailed description of the requirements and functionality of a proposed solution to a specific problem or challenge Source: ISA2-EIF Source reference: https://ec.europa.eu/isa2/eif_en/ Identifier: http://data.europa.eu/dr8/SolutionSpecificationDataObject eira:ID: ABB486 ABB name: eira:SolutionSpecificationDataObject Definition: Controlled Vocabulary ABB is a Data Object that enables a carefully curated set of terms used to describe concepts or objects in a specific field or domain. It is a standardized list of terms that are used to ensure consistency and accuracy in the indexing, searching, and retrieval of information Source: Joinup Source reference: https://joinup.ec.europa.eu/collection/catalogue-services/document/controlled-vocabularies Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/ControlledVocabularyDataObject LOST view: Semantic view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:ControlledVocabularyDataObject Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): EuroVoc - EuroVoc is a multilingual, multidisciplinary thesaurus covering the activities of the EU, the European Parliament in particular. It contains terms in 23 EU languages (Bulgarian, Croatian, Czech, Danish, Dutch, English, Estonian, Finnish, French, German, Greek, Hungarian, Italian, Latvian, Lithuanian, Maltese, Polish, Portuguese, Romanian, Slovak, Slovenian, Spanish and Swedish), plus in three languages of countries which are candidates for EU accession: македонски (mk), shqip (sq) and cрпски (sr). (https://op.europa.eu/en/web/eu-vocabularies/th-dataset/-/resource/dataset/eurovoc) Interoperability Saliency: The Controlled Vocabulary ABB is salient for semantic interoperability because it ensures compatible interpretations of words and phrases used to index content and/or to retrieve content through browsing or searching. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/ControlledVocabularyDataObject EIF Layer: Semantic Definition: Data Format ABB is a Data Object that enables the methods and structures in which data is organized and structured within a file or dataset Source: Inspired in Common European Research Forma Source reference: https://joinup.ec.europa.eu/collection/eu-semantic-interoperability-catalogue/solution/common-european-research-information-format/about Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/DataFormatDataObject LOST view: Semantic view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:DataFormatDataObject Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): European Data Format, a simple and flexible format for the exchange and storage of multichannel biological and physical signals. It was developed by a few European 'medical' engineers who first met at the 1987 international Sleep Congress in Copenhagen. https://www.edfplus.info/). CSV is also a data format https://www.loc.gov/preservation/digital/formats/fdd/fdd000323.shtml Interoperability Saliency: The Data Format Data Object ABB is a key interoperability enabler and salient for semantic interoperability because it provides a common and structured method to organise data, ensuring data quality and successful data exchanges between public administrations and digital public services Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/DataFormatDataObject EIF Layer: Semantic Definition: Ontologies Catalogue ABB is a Data Object aiming at indexing the collection of ontologies with comprehensiveness and trustiness value Source: Joinup Source reference: https://joinup.ec.europa.eu/taxonomy/term/http_e_f_fdata_ceuropa_ceu_fdr8_fOntologiesCatalogue Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/OntologiesCatalogueDataObject LOST view: Semantic view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:OntologiesCatalogueDataObject Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): BioPortal - BioPortal is a repository of over 300 biomedical ontologies and includes tools for working with these ontologies. Holds most widely used Biomedical ontologies. Allows ontologies to be browsed, searched, and reviewed. Allows uses to create notes on ontologies terms. Allows arbitrary text to be annotated with ontology terms. Also supports search of biomedical resources (e.g. PubMed) for combinations of terms from ontologies. Allows programmatic access to ontologies through a REST interface.(http://bioportal.bioontology.org/) Interoperability Saliency: The Ontologies catalogue ABB is a key interoperability enabler (*) for structural interoperability because it ensures the provision/consumption of ontologies by digital public services. Interoperability Dimension: Structural IoP Viewpoint: Key Interoperability Enablers viewpoint Additional identifier: http://data.europa.eu/dr8/OntologiesCatalogueDataObject EIF Layer: Semantic Definition: Data Mapping Catalogue ABB is a Data Object aiming to index an inventory of rules or procedures on how data from different sources and domains can be linked and integrated. Source: European Comision Source reference: https://digital-strategy.ec.europa.eu/en/library/staff-working-document-data-spaces Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/DataMappingCatalogueDataObject LOST view: Semantic view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:DataMappingCatalogueDataObject Example: CEMS Rapid Mapping - JRC - The Joint Research Centre (JRC) is the European Commission's science and knowledge service which employs scientists to carry out research in order to provide independent scientific advice and support to EU policy. Rapid Mapping is one of the two on-demand mapping services under the Copernicus Emergency Management Service (CEMS). Rapid Mapping delivers geospatial information (in different vector and raster formats) in the midst of or immediately after catastrophic events or humanitarian crises. It is available 24/7/365. Supported disaster types range from natural hazards such as floods, fires, storms, tsunamis, volcanic eruptions, landslides, and earthquakes to industrial accidents and humanitarian crises. (https://data.jrc.ec.europa.eu/collection/id-0072) Interoperability Saliency: The Data Mapping Catalogue ABB is a key interoperability enabler (*) for structural interoperability by ensuring the mapping of data by digital public services. Additional information: A data Mapping Catalogue stores the data mappings with comprehensiveness and trustiness value. This ABB is a key interoperability enabler (*) for sharing/PROVISIONING and reusing/CONSUMING Data. Interoperability Dimension: Structural IoP Viewpoint: Key Interoperability Enablers viewpoint Additional identifier: http://data.europa.eu/dr8/DataMappingCatalogueDataObject EIF Layer: Semantic Definition: Forms Structure ABB is a Data Object that enables the implementation of the layout and organization of the fields, labels and controls on a form used to collect or display data. Source: Inspired in Science Direct Source reference: https://www.sciencedirect.com/topics/computer-science/formal-structure Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/FormsStructureDataObject LOST view: Semantic view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:FormsStructureDataObject Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Standard forms for public procurement - o help you publish EU public procurement data in the Official Journal, the European Commission has created standard forms aligned with each of the EU legal bases in place for publishing this data, namely: - TED schema forms set out in Regulation (EU) 2015/1986; - eForms set out in Regulation (EU) 2019/1780. https://simap.ted.europa.eu/standard-forms-for-public-procurement Interoperability Saliency: The Forms Structure Data Object ABB is salient for semantic interoperability because the harmonisation of forms structures can contribute to data accessibility and reuse. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/FormsStructureDataObject EIF Layer: Semantic Definition: Metadata ABB is a Data Object providing information about one or more aspects of the data Source: W3C Source reference: www.w3.org/Metadata/ Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/MetadataDataObject LOST view: Semantic view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:MetadataDataObject Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): https://data.europa.eu/en Interoperability Saliency: The Metadata ABB is a key interoperability enabler (*) for behavioural interoperability by enabling data discoverability and reuse enhancing the delivery and collaboration between digital public services. Interoperability Dimension: Behavioral IoP Viewpoint: Key Interoperability Enablers viewpoint Additional identifier: http://data.europa.eu/dr8/MetadataDataObject EIF Layer: Semantic Definition: Data Model ABB is a Data Object aiming to be a collection of entities, their properties and the relationships among them, which focus at formally representing a domain, a concept or a real-world thing. Source: ISA2 - SEMIC Action Source reference: https://joinup.ec.europa.eu/sites/default/files/methodology_and_tools_for_metadata_governance_and_management_for_eu_institutions.pdf Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/DataModelDataObject LOST view: Semantic view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:DataModelDataObject Interoperability Saliency: The Data Model ABB is salient for semantic interoperability because it ensures compatible interpretations of data exchange as specified in the document "Methodology and tools for metadata governance and management for EU Institutions", developed under the SEMIC action of the ISA Programme: "Whilst technological developments offer various means to automate the exchange of information, technological developments alone cannot guarantee a greater interoperability between information systems. A fundamental aspect is the need for common data standards: primarily data models and reference data [...]". Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): ESPD - Exchange data model - The ESPD Exchange Data Model was designed to implement the data requirements expressed in the Annex 2 of the COMMISSION IMPLEMENTING REGULATION (EU) 2016/7 of 5 January 2016 (from now on "the Annex to the Regulation 2016/7"), establishing the standard form for the European Single Document. Additionally to these requirements, the model took also into account the Information Requirements Model specified by the CEN/BII-Workshops.[3] (namely Workshop 3), and the latest developments relating to the Virtual Company Dossier (VCD) in e-Sens.[4]. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/DataModelDataObject EIF Layer: Semantic Definition: Dataset Catalogue ABB is a Data Object aimed at indexing a collection (inventory) of datasets in a systematic manner. Source: W3C-Data Catalogue Vocabulary Source reference: https://www.w3.org/TR/vocab-dcat/#class-catalog Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/DatasetCatalogueDataObject LOST view: Semantic view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:DatasetCatalogueDataObject Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Agricultural and Vegetable Catalogue - The seed of varieties of agricultural and plant species and varieties of vegetable species that are published in the EU level common catalogue is subject to no marketing restrictions with the Community. Publication in the catalogue must be approved as fulfilling minimum requirements laid down in legislation. Data is published on the contents of the catalogues for agricultural and vegetal species and maintainers with details of the reference list.(https://data.europa.eu/euodp/data/dataset/7A98oEqVa83q6L7tHQ) Interoperability Saliency: The Dataset catalogue ABB is a key interoperability enabler (*) for semantic and structural interoperability by ensuring the provision/consumption of data by digital public services. Additional information: (*)DECISION (EU) 2015/2240 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 25 November 2015 establishing a programme on interoperability solutions and common frameworks for European public administrations, businesses and citizens (ISA2 programme) as a means for modernising the public sector. Interoperability Dimension: Structural IoP Viewpoint: Key Interoperability Enablers viewpoint Additional identifier: http://data.europa.eu/dr8/DatasetCatalogueDataObject EIF Layer: Semantic Definition: Reference data ABB is a Data Object that enables the definition of a set of values or codes that are used to categorize, classify, or describe data elements in a consistent and standardized way Source: Inspired in the book "Managing Reference Data in Enterprise Datavases" Source reference: ISBN1558606971 Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/ReferenceDataDataObject LOST view: Semantic view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:ReferenceDataDataObject Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): GISCO - the Geographic Information System of the COmmission reference data https://ec.europa.eu/eurostat/web/gisco/geodata/reference-data Interoperability Saliency: The Reference Data ABB is a key interoperability enabler because it contributes to data standardisation and provides values and mechanisms to ensure and enable the proper, agreed and successful data exchange between parties and digital public services. Reference Data is a key element for reaching and maintaining data quality. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/ReferenceDataDataObject EIF Layer: Semantic Definition: Data Syntax Mapping Catalogue ABB is an Data Object bridging the differences between two systems, or data models, so that when data is moved from a source, it is accurate and usable at the destination. Source: Inspired in Digital Strategy Europe Source reference: https://digital-strategy.ec.europa.eu/en/library/study-mapping-data-flows Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/DataSyntaxMappingCatalogueDataObject LOST view: Semantic view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:DataSyntaxMappingCatalogueDataObject Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/DataSyntaxMappingCatalogueDataObject EIF Layer: Semantic Definition: Virtual Dataset ABB is a Data Object that enables a dynamic and logical representation of data that aggregates, integrates, or transforms data from multiple sources into a single view Source: H5PY Source reference: https://docs.h5py.org/en/stable/vds.html Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/VirtualDatasetDataObject LOST view: Semantic view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:VirtualDatasetDataObject Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Virtual Datasets (VDS) is an example of a distribution for the creation of virtual datasets. https://docs.h5py.org/en/stable/vds.html Interoperability Saliency: The Virtual Dataset Data Object ABB is salient for semantic interoperability due to its position on and capability for transforming data from different and multiple channels to a single view allowing and increasing the reuse and shareability of data across organisations and digital public services. Interoperability Dimension: Structural IoP Viewpoint: Interoperability Privacy viewpoint Additional identifier: http://data.europa.eu/dr8/VirtualDatasetDataObject EIF Layer: Semantic Definition: API Catalogue ABB is a Data Object that corresponds to a collection of (open) software interfaces that allow data consumption by a specific digital solution Source: Inspired in JRC Source reference: https://data.jrc.ec.europa.eu/dataset/5a431f38-1e2c-449a-898e-34f2a3234c3b Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/APICatalogueDataObject LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:APICatalogueDataObject Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): RapidAPI - RapidAPI is a collection of predefined APIs that are free to test, specifically updated for 2021. https://rapidapi.com/collection/list-of-free-apis Interoperability Saliency: The API Catalogue Data Object ABB is salient for interoperability as it is a collection of software interfaces that allows data consumption between solutions and services. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/APICatalogueDataObject EIF Layer: TechnicalApplication Definition: Distributed Ledger ABB is a Data Object that enables the sharing and recording of encrypted data across multiple sites, countries, or institutions. Source: Regulation of a pilot regime for market infrastructures based on distributed ledger technology Source reference: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:52020PC0594&from=EN Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/DistributedLedgerDataObject LOST view: Semantic view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:DistributedLedgerDataObject Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): TOLAR (https://tolar.io/)is a tool implemented as the outcome of the Seduproject, Hashnet is in the process of evaluation by the European Blockchain Partnership to become one of the pilot protocols for European Blockchain Service Infrastructure. https://www.seedeuproject.eu/partners/hashnet/ Interoperability Saliency: The Distributed Ledger ABB is salient for semantic interoperability due to its capacity to exchange encrypted data amongst digital public services. It is also salient because it can be used across borders to ensure secure and trustworthy data exchange. Additionally, it is also relevant for new technologies incorporating blockchain technology. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/DistributedLedgerDataObject EIF Layer: Semantic Definition: Data mapping ABB is a Data Object aiming to bring equivalence in a relationship between two data items with ontological value. Source: Inspired in "Data Mapping for Data Warehouse Design" book Source reference: https://www.sciencedirect.com/book/9780128051856/data-mapping-for-data-warehouse-design Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/DataMappingDataObject LOST view: Semantic view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:DataMappingDataObject Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Microsoft Dynamics CRM Mapping Schema - Microsoft Dynamics CRM contains several data sets which comprise of different objects, such as Leads, Opportunities, and Competitors. Each of these data sets has several fields like Name, Account Owner, City, Country, Job Title, and more. The application has a defined schema along with attributes, enumerations, and mapping rules. Therefore, if a new record is to be added to the schema of a data object, a data map needs to be created from the data source to the Microsoft Dynamics CRM account. Interoperability Saliency: The Data Mapping ABB is a key interoperability enabler because it supports to achieve legal behavioral interoperability by enabling the exchange of data, information, and knowledge between digital public services. Additional information: Data mapping is used for a wide variety of tasks, including: - Data mediation between a data source and a destination; - Data transformation; - Identification of data relationships as part of data lineage analysis; - Discovery of hidden sensitive data such as the last four digits of a social security number hidden in another user id as part of a data masking or de-identification project; - Consolidation of multiple databases into a single database and identifying redundant columns of data for consolidation or elimination. Viewpoint: Interoperability Privacy viewpoint Additional identifier: http://data.europa.eu/dr8/DataMappingDataObject EIF Layer: Semantic Interoperability Dimension: Structural IoP Definition: Knowledge Triplestore ABB is a Data Object that enables storage, management and retrieval of data in the form of triples, data entities composed of subject-predicate-object. Source: W3C Source reference: https://www.w3.org/2001/sw/Europe/events/20031113-storage/positions/rusher.html Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/KnowledgeTriplestoreDataObject LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:KnowledgeTriplestoreDataObject Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): CELLAR. Cellar metadata is stored in a knowledge graph, and more specifically in a triple store. A SPARQL interface is used to query the metadata. https://op.europa.eu/en/web/cellar/cellar-data/metadata/knowledge-graph Interoperability Saliency: The Knowledge Triplestore Data Object ABB is salient for technical interoperability because it represents the different data objects such as databases storing data, allowing to manage and retrieve of data from different sources and digital public services. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/KnowledgeTriplestoreDataObject EIF Layer: TechnicalApplication Definition: Ontology ABB is a Data Object that defines a set of representational primitives with which to model a domain of knowledge or discourse Source: Formal definiion of Tom Gruber Source reference: https://tomgruber.org/writing/definition-of-ontology Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/OntologyDataObject LOST view: Semantic view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:OntologyDataObject Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Medical Dictionary for Regulatory Activities Terminology (MedDRA) - The university ontology includes classes, e.g., :Staff, :Students, :Department or :Course. These classes denote natural concepts that are shared or at least understood by users familiar with universities all over the world. Universities ontologies can be view in university portals.(http://bioportal.bioontology.org/ontologies/MEDDRA) Interoperability Saliency: The Ontology ABB is salient for semantic interoperability because it defined as a simplified, reusable and extensible data model that capture the fundamental characteristics of a data entity in a context-neutral and syntax-neutral fashion. Additional information: Ontology ABB is a Data Object aiming to be a formal description of knowledge, as a set of concepts, within a domain and the axioms connecting concepts and allowing for logic inferences. When speaking about an ontology, we do not refer only to the terminology (or T-Box) but also to all the “assertions” about the concepts and roles (the A-Box), i.e. all the individuals or instances of concepts and roles of the terminology and as important, the rules for logic inference: the semantics “part". Interoperability Dimension: Structural IoP Viewpoint: Interoperability Privacy viewpoint Additional identifier: http://data.europa.eu/dr8/OntologyDataObject EIF Layer: Semantic Definition: Data Syntax ABB is a Data Object defining the way in which data is put together with appropriate identifiers, delimiters, separator character(s), and other non-data characters to form messages. Source: ISO Source reference: https://www.iso.org/obp/ui/#iso:std:iso:14817:-1:ed-1:v1:en:term:4.59 Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/DataSyntaxDataObject LOST view: Semantic view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:DataSyntaxDataObject Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): XML syntax - XML syntax refers to the rules that determine how an XML application can be written. The XML syntax is very straight forward, and this makes XML very easy to learn. Below are the main points to remember when creating XML documents.(https://www.quackit.com/xml/tutorial/xml_syntax.cfm) Interoperability Saliency: The Data Syntax ABB is salient for semantic interoperability because it provides the rules establishing how data have to to be written. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/DataSyntaxDataObject EIF Layer: Semantic Definition: Data ABB is a Data Object that enables the implementation of digital or non-digital information that is collected, stored, or processed by a computer system or other information technology infrastructure. This information can take many forms, including text, numbers, images, video, audio, and more. Source: ISO-IEC-2382-1 * 1993 * Source reference: https://www.iso.org/obp/ui/#iso:std:iso-iec:2382:ed-1:v1:en Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/DataDataObject LOST view: Semantic view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:DataDataObject Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): https://www.eea.europa.eu/data-and-maps/dashboards/emissions-trading-viewer-1 Interoperability Saliency: The Data ABB is salient for semantic interoperability because it represents the most important mean of interaction between ICT systems of organisations in order to ensure interoperability as stated in the EIF recommendation n° 30: "Perceive data and information as a public asset that should be appropriately generated, collected, managed, shared, protected and preserved." Interoperability Dimension: Structural IoP Viewpoint: Interoperability Privacy viewpoint Additional identifier: http://data.europa.eu/dr8/DataDataObject EIF Layer: Semantic Definition: Hash Code ABB is a Data Object that enables the implementation of a numeric or alphanumeric string obtained by the application of an algorithm that turns a variable amount of data into a small, fixed-length value Source: Inspired in CROS Source reference: https://ec.europa.eu/eurostat/cros/content/data-hashing_en Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/HashCodeDataObject LOST view: Semantic view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:HashCodeDataObject Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): The hash code is a relevant tool used, for instance, in the personal data pseudonymisation technique. https://edps.europa.eu/sites/edp/files/publication/19-10-30_aepd-edps_paper_hash_final_en.pdf Interoperability Saliency: The Hash Code Data Object ABB is salient for semantic interoperability because it supports semantic interoperability by providing alphanumeric strings comprising a variable amount of data. This enables and supports interoperability by reducing data and changing from comprehensible data to anonymised strings. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/HashCodeDataObject EIF Layer: Semantic Definition: Dataset ABB is a Data Object representing a collection of related data that is organized and presented in a structured format Source: Inpired in the Open Data and Re-use of public sector inforamtion directive Source reference: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32019L1024&from=EN#d1e1012-56-1 Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/DatasetDataObject LOST view: Semantic view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:DatasetDataObject Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): European Union Data Portal - The European Union Open Data Portal (EU ODP) gives you access to open data published by EU institutions and bodies. All the data you can find via this catalogue are free to use and reuse for commercial or non-commercial purposes. (https://data.europa.eu/euodp/data/dataset) Interoperability Saliency: The Data Set ABB is salient for semantic interoperability because it provides a collection of data to be shared or exchanged between ICT systmes as stated in the EIF recommendation n° 30: "Perceive data and information as a public asset that should be appropriately generated, collected, managed, shared, protected and preserved." Additional information: It is useful to remember that when a common interconnecting infrastructure for base registries is available, legislation is used to force its use. The use of interconnecting infrastructure prevents the proliferation of pointto-point interconnections. Stakeholders should be involved in developing the legislation and be given enough time to prepare for implementation. Interoperability Dimension: Structural IoP Viewpoint: Interoperability Privacy viewpoint Additional identifier: http://data.europa.eu/dr8/DatasetDataObject EIF Layer: Semantic Definition: Software Components Catalogue ABB is a Data Object aiming to index information about collaborative spaces that offfers eGoverment solutions and best practices. Source: Joinup Source reference: https://joinup.ec.europa.eu/topic/ict/reusable-software-components Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/SoftwareComponentsCatalogueDataObject LOST view: Semantic view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:SoftwareComponentsCatalogueDataObject Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Software ReUse Catalogue (Belgium) https://joinup.ec.europa.eu/collection/belgian-interoperability-catalogue/solution/ict-reuse/about Interoperability Saliency: The Software Components Catalogue Data Object ABB is salient for semantic interoperability because it can act as a repository with descriptive data about digital solutions and interoperable solutions and best practices. This can contribute to expanding and enabling the reuse of artefacts, solutions, and services to implement new digital public services without starting from scratch. The reuse of such elements can infer knowledge and best practices from the collaboration between parties. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/SoftwareComponentsCatalogueDataObject EIF Layer: Semantic Definition: Metadata Catalogue ABB is a Data Object that represents the collection of of descriptive information about data, resources or information objects related to public services. Source: INSPIRE Source reference: https://inspire.ec.europa.eu/training/metadata-and-catalogue-services Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/MetadataCatalogueDataObject LOST view: Semantic view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:MetadataCatalogueDataObject Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): CESSDA Data Catalogue https://www.cessda.eu/Tools/Data-Catalogue Interoperability Saliency: The Metadata Catalogue ABB is a key interoperability enabler supporting semantic interoperability because metadata catalogue is a collection of descriptive information about data and information related to digital public services. The usage of standardised methods can enable successful data discoverability and reuse supporting the implementation of digital public services across borders. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/MetadataCatalogueDataObject EIF Layer: Semantic DEFINITION: Network ABB is a Communication Network being used as a transmission systems and, where applicable, switching or routing equipment and other resources which permit the conveyance of signals by wire, by radio, by optical or by other electromagnetic means, including satellite networks, fixed (circuit- and packet- switched, including Internet) and mobile terrestrial networks, electricity cable systems, to the extent that they are used for the purpose of transmitting signals, networks used for radio and television broadcasting, and cable television networks, irrespective of the type of information conveyed. Source: DIRECTIVE 2002/21/EC on a common regulatory framework for electronic communications networks and services (http://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32002L0021&from=EN) INTEROPERABILITY SALIENCY: IoP Dimension: Structural IoP The Network ABB is salient for technical interoperability because it provides the network where can operate interoperable solutions (both public and private network). EXAMPLES: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): sTESTA The TESTA network service – which stands for Trans European Services for Telematics between Administrations – provides a European backbone network for data exchange between a wide variety of public administrations. The network uses the Internet Protocols (IP) to ensure universal reach, but is operated by the EU Commission separately from the Internet. It provides guaranteed performance and a high level of security and has connections with all the EU Institutions and national networks. It caters for the exchange of both unclassified and classified information. Source: (https://ec.europa.eu/isa2/solutions/testa_en) DEFINITION: Private Hosting Facility ABB is a Node meaning the equipment supporting the hosting of Interoperable European Solutions and their components, usually embodied in a build-in, which is owned by or dedicated to one organization (e.g. data centre or private cloud). Source: DIGIT C Infrastructure Services Provision (http://ec.europa.eu/ipg/build/infrastructure/index_en.htm) INTEROPERABILITY SALIENCY: IoP Dimension: Structural IoP The Private Hosting Facility ABB is salient for technical interoperability because it provides all the equipment, dedicated to one organization, supporting the hosting of interaoperable solutions and their components. EXAMPLES: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): DG TAXUD Surveillance3 IES Datawarehouse servers hosted in DG TAXUD Data Centre The Surveillance3 Data Warehouse plays multiple roles: • The role of ‘hub-and-spoke’ within the Surveillance3 system where data from different systems are integrated and linked and made available for report & analytics as well as the central place from which other systems are fed with the correct information. • The role of reporting environment offering all the required reporting, data analysis & discovery and data mining functionality. Source: (https://ec.europa.eu/assets/taxud/taxation_customs/tenders/2016ao02_a2_technical_en.pdf) DEFINITION: Public Hosting Facility ABB is a Node supporting the hosting of Interoperable European Solutions and their components, usually embodied in a building, which is owned by a third party and shared between organizations (e.g. cloud services). Source: DIGIT C Infrastructure Services Provision (http://ec.europa.eu/ipg/build/infrastructure/index_en.htm) INTEROPERABILITY SALIENCY: IoP Dimension: Structural IoP The Public Hosting Facility ABB is salient for technical interoperability because it provides all the equipment, shared between organizations, supporting the hosting of interaoperable solutions and their components. EXAMPLES: Amazon Web Services (AWS) AWS provides a comprehensive suite of services and solutions to run sophisticated and scalable applications to help achieve better business outcomes. Running your applications in the AWS Cloud can help you move faster, operate more securely, and save substantial costs; all while benefitting from the agility, scale and performance of the cloud. Source: (https://aws.amazon.com/solutions/?nc2=h_ql_sol) DEFINITION: Networking Service ABB is a Technology Service being provided by a network provider which is the combination of transmission systems and, where applicable, switching or routing equipment and other resources which permit the conveyance of signals by wire, by radio, by optical or by other electromagnetic means, including satellite networks, fixed (circuit- and packet- switched, including Internet) and mobile terrestrial networks, electricity cable systems, to the extent that they are used for the purpose of transmitting signals, networks used for radio and television broadcasting, and cable television networks, irrespective of the type of information conveyed. Source: DIRECTIVE 2002/21/EC on a common regulatory framework for electronic communications networks and services (http://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32002L0021&from=EN) INTEROPERABILITY SALIENCY: IoP Dimension: Behavioural IoP The Networking Service ABB is salient for technical interoperability because it provides all the required functionalities in order to create the suitable network underlayer where can operate interoperable solutions. EXAMPLES: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): sTESTA The TESTA network service – which stands for Trans European Services for Telematics between Administrations – provides a European backbone network for data exchange between a wide variety of public administrations. The network uses the Internet Protocols (IP) to ensure universal reach, but is operated by the EU Commission separately from the Internet. It provides guaranteed performance and a high level of security and has connections with all the EU Institutions and national networks. It caters for the exchange of both unclassified and classified information. Source: (https://ec.europa.eu/isa2/solutions/testa_en) Definition: Interoperable Digital Solution ABB is an Artifact that refers to the software or hardware system that is designed to work seamlessly with other systems or technologies Source: ISA2-EIF Source reference: https://ec.europa.eu/isa2/eif_en/ Identifier: http://data.europa.eu/dr8/DigitalSolutionArtifact eira:ID: ABB611 ABB name: eira:DigitalSolutionArtifact Definition: Solution Building Block ABB is an Artifact that enables the implementation of one or more EIRA Architecture Building Blocks of a European Public Service. Source: ISA2 Source reference: https://ec.europa.eu/isa2/sites/default/files/e-government_core_vocabularies_handbook.pdf Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/SolutionBuildingBlockArtifact LOST view: Legal view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:SolutionBuildingBlockArtifact Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): TOLAR (https://tolar.io/)is a tool implemented as the outcome of the Seduproject, Hashnet is in the process of evaluation by the European Blockchain Partnership to become one of the pilot protocols for European Blockchain Service Infrastructure. https://www.seedeuproject.eu/partners/hashnet/ Interoperability Saliency: The Solution Building Block ABB is salient for the technical interoperability due to establishing the technical aspects related to the definition of architecture and public service architectural principles to support public administration in the service delivery. Additional information: Solution Builsing Block ABB is formulated as an agreed normative statement in design terms on a legal, organisational, semantic, or technical attribute of an European Public Service. On the technical view, a Solution Building Block is a specific software component that it might be either procured or developed of a To-Be Interoperable European Solution or that it is integrated in an As-Is Interoperable European Solution Interoperability Dimension: Structural IoP Viewpoint: EIRA Ontology viewpoint Additional identifier: http://data.europa.eu/dr8/SolutionBuildingBlockArtifact EIF Layer: N/A Definition: Private Subnetwork ABB is a Communication Network that enables the implementation of a subset of a larger network that is isolated and only accessible to a specific group of devices or users Source: ISA2 - EIA Action Source reference: https://ec.europa.eu/isa2/actions/towards-european-interoperability-architecture_en/ Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/PrivateSubnetworkCommunicationNetwork LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:PrivateSubnetworkCommunicationNetwork Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): ECC Report 301. https://docdb.cept.org/download/1395 Interoperability Saliency: The private subnetwork ABB is salient for technical interoperability because it provides custom private areas to share internal information about specific public administration internal services. These areas are only accessible by a restricted number of people and/or devices. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/PrivateSubnetworkCommunicationNetwork EIF Layer: TechnicalInfrastructure Definition: Cloud Private Network ABB is a Communication Network that enables a virtual network that connects resources and services within a cloud computing environment. Source: Inspired in referent cloud service providers definitions Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/CloudPrivateNetworkCommunicationNetwork LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:CloudPrivateNetworkCommunicationNetwork Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): JRC- Development of the EU Green Public Procurement (GPP)- Criteria for Data Centres, Server Rooms and Cloud Services. https://ec.europa.eu/environment/gpp/pdf/jrc118558_2020_0605_data_centres_technical_report_jrc_clean_with_id.pdf Interoperability Saliency: The Cloud Private Network ABB is salient for technical interoperability because it provides the needed infrastructure connection between cloud service providers to a specific group of people, organizations or systems. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/CloudPrivateNetworkCommunicationNetwork EIF Layer: TechnicalInfrastructure Definition: Private Network ABB is a Communication Network that enables the implementation of a network used for realising the physical communication among Interoperable European Solution (e.g. sTESTA), and cannot be accessed by the public. Source: ISA2 - EIA Action Source reference: https://ec.europa.eu/isa2/actions/towards-european-interoperability-architecture_en/ Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/PrivateNetworkCommunicationNetwork LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:PrivateNetworkCommunicationNetwork Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): ECC Report 301. https://docdb.cept.org/download/1395 Interoperability Saliency: Private Network ABB is salient for technical interoperability because it implements and establishes the basis of the network of the public administration private area for exchanging, storing and sharing information at the internal level. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/PrivateNetworkCommunicationNetwork EIF Layer: TechnicalInfrastructure Definition: Public Network ABB is a Communication Network that enables access to the public (public administrations, businesses and citizens) without specific authorisations. Interoperable European Solutions can rely on Public Networks (e.g. the Internet) to realise the physical communication between nodes. Source: ISA2 - EIA Action Source reference: https://digital-strategy.ec.europa.eu/en/news/isa2-interoperability-solutions-european-public-administrations-first-work-programme-adopted Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/PublicNetworkCommunicationNetwork LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:PublicNetworkCommunicationNetwork Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): World-Wide-Web (WWW) - The WorldWideWeb (W3) is a wide-area hypermedia information retrieval initiative aiming to give universal access to a large universe of documents. Interoperability Saliency: The Public Network ABB is salient for technical interoperability due to it provides the network infrastructure to facilitate access to the public administration digital service to the general public. Interoperability Dimension: Structural IoP Viewpoint: REST API viewpoint Additional identifier: http://data.europa.eu/dr8/PublicNetworkCommunicationNetwork EIF Layer: TechnicalInfrastructure Definition: Local Area Network ABB is a Communication Network that enables the connection of devices and computers within a limited area. Source: Networkbits Source reference: https://web.archive.org/web/20201026082752/http://networkbits.net/lan-components/local-area-network-lan-basic-components/ Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/LocalAreaNetworkCommunicationNetwork LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:LocalAreaNetworkCommunicationNetwork Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): European Commission. https://ec.europa.eu/commission/presscorner/detail/en/MEMO_05_256 Interoperability Saliency: The Local Area Network ABB is salient for technical interoperability as the infrastructure that can connect devices and tools within a limited area of the public administration. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/LocalAreaNetworkCommunicationNetwork EIF Layer: TechnicalInfrastructure Definition: Secure Public Network ABB is a Communication Network that enables access to the public, but is designed and configured to protect against unauthorized access and cyber threats Source: ISA2 - EIA Action Source reference: https://digital-strategy.ec.europa.eu/en/news/isa2-interoperability-solutions-european-public-administrations-first-work-programme-adopted Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/SecurePublicNetworkCommunicationNetwork LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:SecurePublicNetworkCommunicationNetwork Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): World-Wide-Web (WWW) - The WorldWideWeb (W3) is a wide-area hypermedia information retrieval initiative aiming to give universal access to a large universe of documents. Interoperability Saliency: Secure Public Network ABB is salient for technical interoperability because it set up the network infrastructure to establish secure communications with the public administration services. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/SecurePublicNetworkCommunicationNetwork EIF Layer: TechnicalInfrastructure Definition: Sensor ABB is a Device that that detects and responds to events or changes in the physical environment. Source: Inspired in SAREF Source reference: https://saref.etsi.org/core/Sensor Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/SensorDevice LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:SensorDevice Interoperability Saliency: The Sensor ABB is salient for technical interoperability because it provides needed observational elements to measure specific elements that serve to improve eGovernance services. Additional information: Sensors convert physical inputs into electrical signals that can be processed and analyzed by electronic systems or software Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/SensorDevice EIF Layer: TechnicalInfrastructure Definition: Remote Desktop Client ABB is a Device that enables access, control and interaction with a remote computer located anywhere through the internet or internal network. Source: Inspired in Gartner Source reference: https://www.gartner.com/en/information-technology/glossary/remote-access Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/RemoteDesktopClientDevice LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:RemoteDesktopClientDevice Interoperability Saliency: The Remote Desktop Client ABB is salient for technical interoperability because it provides the physical element to remotely connect to shared workspaces to access public services. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/RemoteDesktopClientDevice EIF Layer: TechnicalInfrastructure Definition: Desktop Computer ABB is a Device in which the main unit is in a permanent location and is not designed for portability and is designed for use with an external display and external peripherals such as a keyboard and mouse. Source: European Comission Source reference: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32013R0617 Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/DesktopComputerDevice LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:DesktopComputerDevice Interoperability Saliency: The Desktop Computer ABB is salient for technical interoperability because it provides the physical element to communicate with public services. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/DesktopComputerDevice EIF Layer: TechnicalInfrastructure Definition: Smart Device ABB is a Device that can operate interactively and autonomously, connected to other devices or networks through different communication protocols. Source: European Comission Source reference: https://digital-strategy.ec.europa.eu/en/policies/internet-things-policy Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/SmartDeviceDevice LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:SmartDeviceDevice Synonym: Interoperability Saliency: The Smart Device ABB is salient for technical interoperability because it provides the physical element to exchange information and events with the public administration digital services. Additional information: Smart devices typically incorporate sensors, processors, and connectivity technology, such as Wi-Fi or Bluetooth, that allow them to collect and exchange data Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/SmartDeviceDevice EIF Layer: TechnicalInfrastructure Definition: The Physical Network Infrastructure ABB is an Equipment that enables connectivity and communication between users, devices, apps and the Internet. Source: Inspired on relevant Physical Network Infrastructure providers Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/PhysicalNetworkInfrastructureEquipment LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:PhysicalNetworkInfrastructureEquipment Interoperability Saliency: The Physical Network Infrastructure ABB is salient for technical interoperability because it provides the infrastructure to facilitate the hosting and execution of public administration services. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/PhysicalNetworkInfrastructureEquipment EIF Layer: TechnicalInfrastructure Definition: The Physical Communication Infrastructure ABB is an Equipment that enables components to exchange data. Source: Law Insider Source reference: https://www.lawinsider.com/dictionary/communication-infrastructure Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/PhysicalCommunicationInfrastructureEquipment LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:PhysicalCommunicationInfrastructureEquipment Interoperability Saliency: The Physical Communication Infrastructure ABB is salient for technical interoperability because it provides the infrastructure in charge of bringing the data exchange and communication between public administration services. Additional information: The Physical Communication Infrastructure includes but is not limited to fixed links, radio communication transmitters, fibre/copper cable, towers, switches, base stations. Customer premise equipment is not included. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/PhysicalCommunicationInfrastructureEquipment EIF Layer: TechnicalInfrastructure Definition: Physical Power Supply Infrastructure ABB is Equipment that enables reliable and uninterrupted electrical power to support the operation of public administration systems. Source: Inspired in Lawinsider Source reference: https://www.lawinsider.com/dictionary/power-supply-infrastructure Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/PhysicalPowerSupplyInfrastructureEquipment LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:PhysicalPowerSupplyInfrastructureEquipment Interoperability Saliency: The Physical Power Supply Infrastructure ABB is salient for the technical interoperability due to it provides electrical supply to the public administration systems for ensuring their availability according to the service level agreements. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/PhysicalPowerSupplyInfrastructureEquipment EIF Layer: TechnicalInfrastructure Definition: Physical Security Infrastructure ABB is Equipment that enables the protection of facilities and assets from actions and events that could cause damage or losses. Source: Inspired in Gartner Source reference: https://www.gartner.com/en/information-technology/glossary/physical-security Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/PhysicalSecurityInfrastructureEquipment LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:PhysicalSecurityInfrastructureEquipment Interoperability Saliency: The Physical Security Infrastructure ABB is salient for technical interoperability because it provides the infrastructure capable of providing functionalities of data protection and privacy. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/PhysicalSecurityInfrastructureEquipment EIF Layer: TechnicalInfrastructure Definition: The Physical Computing Infrastructure ABB is an Equipment that enables the processing, storage, and transmission of data in a computing environment. Source: Inspired on relevant IT infrastructure providers Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/PhysicalComputingInfrastructureEquipment LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:PhysicalComputingInfrastructureEquipment Interoperability Saliency: The Physical Computing Infrastructure ABB is salient for technical interoperability because it establishes the infrastructure to analyse a large amount of information. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/PhysicalComputingInfrastructureEquipment EIF Layer: TechnicalInfrastructure Definition: Hybrid Cloud Facility ABB is a Facility that enables a mix of cloud computing services combining at least one private cloud and one public cloud working together. Source: Inspired in referent cloud service providers Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/HybridCloudFacilityFacility LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:HybridCloudFacilityFacility Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): JRC- Development of the EU Green Public Procurement (GPP)- Criteria for Data Centres, Server Rooms and Cloud Services. https://ec.europa.eu/environment/gpp/pdf/jrc118558_2020_0605_data_centres_technical_report_jrc_clean_with_id.pdf Interoperability Saliency: The Hybrid Cloud Facility ABB is salient for organizational and technical interoperability because it provides a set of business rules and responsibilities to the administration of public administration services. Moreover, it also provides the needed infrastructure to manage private and public services remotely. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/HybridCloudFacilityFacility EIF Layer: TechnicalInfrastructure Definition: Hosting Facility ABB is a Facility that enables components and services to make public services available on the Internet for their use. Source: Law Insider Source reference: https://www.lawinsider.com/dictionary/hosting-facility#:~:text=Hosting%20Facility%20means%20a%20third,for%20use%20by%20End%20Users. Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/HostingFacilityFacility LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:HostingFacilityFacility Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): DIGIT/C Hosting Facility - DIGIT/C offers a high availability and high-performance hosting infrastructure that is comprised, among other elements, of back-end web server instances and application servers for hosting and serving both static and dynamic sites. The dynamic sites supported by the standard Apache web servers are mainly sites based on Coldfusion and in some cases also sites using CGI scripts. Dynamic sites based on particular technologies (i.e. Weblogic) are being hosted on individual application servers and are being integrated with the other related sites using reverse proxy mappings. Direct HTTP access to the back-end web servers hosting the static sites is denied by the standard web server configuration. http://ec.europa.eu/ipg/build/infrastructure/index_en.htm Interoperability Saliency: Hosting Facility ABB is salient for the technical interoperability because it establish the set up of IT systems to deliver the different public administration digital services and architectures that permit to integrate data from different infrastructure and remove existing IT silos in public administration. Interoperability Dimension: Structural IoP Viewpoint: Interoperability Security viewpoint Additional identifier: http://data.europa.eu/dr8/HostingFacilityFacility EIF Layer: TechnicalInfrastructure Definition: On Premise Facility ABB is a Facility referring to to a physical location, such as an office or data center, that is owned and managed by a business or organization Source: Inspired in The Free Dictionary Source reference: https://encyclopedia2.thefreedictionary.com/Facility Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/OnPremiseFacilityFacility LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:OnPremiseFacilityFacility Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): JRC- Development of the EU Green Public Procurement (GPP)- Critaria for Data Centres, Server Rooms and Cloud Services. https://ec.europa.eu/environment/gpp/pdf/jrc118558_2020_0605_data_centres_technical_report_jrc_clean_with_id.pdf Interoperability Saliency: The On Premise Facility ABB is salient for organizational interoperability because it establishes the business rules and responsibilities to place the public administration ICT infrastructure in a custom location. Interoperability Dimension: Structural IoP Viewpoint: Interoperability Security viewpoint Additional identifier: http://data.europa.eu/dr8/OnPremiseFacilityFacility EIF Layer: TechnicalInfrastructure Definition: Private Cloud Computing Facility ABB is a Facility that enables a cloud infrastructure that is exclusively dedicated to a single organization or user. Source: Inspired in Redhat Source reference: https://www.redhat.com/en/topics/cloud-computing/public-cloud-vs-private-cloud-and-hybrid-cloud Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/PrivateCloudComputingFacilityFacility LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:PrivateCloudComputingFacilityFacility Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): JRC- Development of the EU Green Public Procurement (GPP)- Critaria for Data Centres, Server Rooms and Cloud Services. https://ec.europa.eu/environment/gpp/pdf/jrc118558_2020_0605_data_centres_technical_report_jrc_clean_with_id.pdf Interoperability Saliency: Private Cloud Facilities ABB is salient for organizational and technical interoperability because it establishes the business rules and responsibilities to expose public digital services that are restricted for the use of custom organizations, users or devices. Interoperability Dimension: Structural IoP Viewpoint: Interoperability Security viewpoint Additional identifier: http://data.europa.eu/dr8/PrivateCloudComputingFacilityFacility EIF Layer: TechnicalInfrastructure Definition: Public Cloud Computing Facility ABB is a Facility that enables a cloud infrastructure that is shared among multiple users and organizations and is typically managed by a third-party service provider Source: Inpired in Redhat Source reference: https://www.redhat.com/en/topics/cloud-computing/public-cloud-vs-private-cloud-and-hybrid-cloud Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/PublicCloudComputingFacilityFacility LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:PublicCloudComputingFacilityFacility Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): JRC- Development of the EU Green Public Procurement (GPP)- Critaria for Data Centres, Server Rooms and Cloud Services. https://ec.europa.eu/environment/gpp/pdf/jrc118558_2020_0605_data_centres_technical_report_jrc_clean_with_id.pdf Interoperability Saliency: Public Cloud Facilities ABB is salient for organizational and technical interoperability because it establishes the business rules and responsibilities to deploy and deliver public administration services remotely. Interoperability Dimension: Structural IoP Viewpoint: Interoperability Security viewpoint Additional identifier: http://data.europa.eu/dr8/PublicCloudComputingFacilityFacility EIF Layer: TechnicalInfrastructure Definition: External Facility ABB is a Facility that enables a physical location or infrastructure that is owned or operated by a third-party organization and used by another organization or individual. These facilities may include office buildings, data centres, warehouses, manufacture Source: ISA2-EIA Source reference: https://ec.europa.eu/isa2/actions/towards-european-interoperability-architecture_en/ Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/ExternalFacilityFacility LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:ExternalFacilityFacility Interoperability Saliency: The External Facility ABB is saliency for organizational and technical interoperability because it establishes the business rules and responsibilities to share infrastructures for the use of public administrations. The ABB also provides the application of open specifications and solutions to make interoperable public administration solutions. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/ExternalFacilityFacility EIF Layer: TechnicalInfrastructure Definition: Cloud Computing Facility ABB is a Facility that enables the storage, processing and use of data on remotely located devices accessed over the internet Source: European Comission-Unleashing the Potential of Cloud Computing in Europe Source reference: https://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=COM:2012:0529:FIN:en:PDF Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/CloudComputingFacilityFacility LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:CloudComputingFacilityFacility Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): FENIX is an infrastructure research project that incorporates cloud computing facilities from ICT Solutions for Brilliant Minds. https://fenix-ri.eu/about-fenix/project-partners Interoperability Saliency: The Cloud Computing Facility ABB is salient for organizational interoperability due to it provides the business rules and responsibilities to publish and manage the public administration services. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/CloudComputingFacilityFacility EIF Layer: TechnicalInfrastructure Definition: Server ABB is a Node that enables access to resources or services to other computers or devices on a network Source: Gartner Source reference: https://www.gartner.com/en/information-technology/glossary/clientserver Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/ServerNode LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:ServerNode Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): DIGIT/C Hosting Service - DIGIT/C offers a high availability and high performance hosting infrastructure that is being comprised, among other elements, of back-end web server instances and application servers for hosting and serving both static and dynamic sites. http://ec.europa.eu/ipg/build/infrastructure/index_en.htm Interoperability Saliency: The Server ABB is salient for technical interoperability because it provides the capabilities to host public administration services at both levels, internally and externally. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/ServerNode EIF Layer: TechnicalInfrastructure Definition: Virtual Machine ABB is a Node that enables the emulation of a physical computer to run programs and deploy applications. Source: Inspired in Redhat Source reference: https://www.redhat.com/en/topics/virtualization/what-is-a-virtual-machine Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/VirtualMachineNode LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:VirtualMachineNode Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Redhat Virtualization: Built on Red Hat Enterprise Linux® and KVM and fully maintained by Red Hat, Red Hat® Virtualization is an enterprise virtualization platform that supports core virtualization workloads, including resource-intensive and important applications. With a solid foundation for a cloud-native and containerized future, virtualize your resources, workflows, and software applications. Additionally compatible with platforms like Microsoft Exchange and the Oracle database is Red Hat Enterprise Virtualization. https://www.redhat.com/en/technologies/virtualization/enterprise-virtualization Interoperability Saliency: The Virtual Machine ABB is salient for technical interoperability because it provides needed tools to emulate the public administration services under controlled environments. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/VirtualMachineNode EIF Layer: TechnicalInfrastructure Definition: Container ABB is a Technology Service that implements an executable unit of software in which application code is packaged, along with its libraries and dependencies, in common ways so that it can be run anywhere, whether it be on a desktop, traditional IT, or the cloud Source: Inspired in referent cloud service providers Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/ContainerSystemSoftware LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:ContainerSystemSoftware Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Docker. Docker is a containerization technology that works with the Kubernetes platform, with many adopting it to create an app that runs across multiple containers. https://www.docker.com/ Interoperability Saliency: Container ABB is salient for technical interoperability because it provides the packaged software that contains or nurtures the functionalities of public services. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/ContainerSystemSoftware EIF Layer: TechnicalInfrastructure Definition: Edge Computing ABB is a Technology Collaboration that enables the procedures to implement a distributed computing topology where information processing is located close to the edge, where things and people produce or consume that information Source: Gartner Source reference: https://www.gartner.com/en/information-technology/glossary/edge-computing Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/EdgeComputingTechnologyCollaboration LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:EdgeComputingTechnologyCollaboration Synonym: Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): SovereignEDGE.eu https://sovereignedge.eu/ Interoperability Saliency: The Edge Computing ABB is salient for technical interoperability because it provides needed computational elements and tools to perform data analytics in specific devices that can nurture public administration digital services (e.g. mobiles from citizens). Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/EdgeComputingTechnologyCollaboration EIF Layer: TechnicalInfrastructure Definition: Technology Interface ABB is an archimate Technology Interface that represents a point of access where technology services offered by a technology internal active structure element can be accessed. Source: Inspired in Archimate Source reference: https://pubs.opengroup.org/architecture/archimate3-doc/chap10.html Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/TechnologyInterfaceTechnologyInterface LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:TechnologyInterfaceTechnologyInterface Synonym: Interoperability Saliency: Technology Interface ABB is a key interoperability enabler (*) for behavioural, technical and semantic interoperability by enabling interfaces and access points to the architectures for infrastructure-to-infrastructure data exchange. Additional information: A technology interface specifies how the technology services of a technology internal active structure element can be accessed by other elements. A technology interface exposes a technology service to the environment. The same service may be exposed through different interfaces. Interoperability Dimension: Behavioral IoP Viewpoint: Key Interoperability Enablers viewpoint Additional identifier: http://data.europa.eu/dr8/TechnologyInterfaceTechnologyInterface EIF Layer: TechnicalInfrastructure Definition: Containers Orchestration ABB is a Technology Service that enables the procedures to automate the deployment, management, scaling, and networking of containers Source: Red Hat Source reference: https://www.redhat.com/en/topics/containers/what-is-container-orchestration Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/ContainersOrchestratorTechnologyService LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:ContainersOrchestratorTechnologyService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): OpenSHIFT is a secure and an enterprise-grade cloud-based container orchestration system with Kubernetes at the backend. It can be used both as a Red Hat Container Orchestration Engine and Platform-as-a-Service (PaaS). https://github.com/openshift/origin Interoperability Saliency: Containers Orchestrator ABB is salient for technical interoperability due to it provides the mechanism and networks to organize virtual public services and tools to facilitate the deployment and publication of public digital services. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/ContainersOrchestratorTechnologyService EIF Layer: TechnicalInfrastructure Definition: Machine Learning ABB is a Technology service that enables the procedures for implementing algorithms and models that can learn from and make predictions on data Source: European Comision-White paper on AI Source reference: https://commission.europa.eu/system/files/2020-02/commission-white-paper-artificial-intelligence-feb2020_en.pdf Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/MachineLearningTechnologyService LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:MachineLearningTechnologyService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): AI Whatch Artificial Intelligence in public administrations. https://publications.jrc.ec.europa.eu/repository/bitstream/JRC120399/jrc120399_misuraca-ai-watch_public-services_30062020_def.pdf Interoperability Saliency: Machine Learning ABB is salient for semantic interoperability because it refers to the generation of newer insights (knowledge) from public data to generate (i) new curated datasets and/or (ii) new public data assets based on the combination of other public data. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/MachineLearningTechnologyService EIF Layer: TechnicalInfrastructure Definition: Logger ABB is a Technology Service that enables the procedures recording events or messages that occur within a system or application Source: Inspired in Gartner Source reference: https://www.gartner.com/en/information-technology/glossary/event-fault-and-log-management Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/LoggerTechnologyService LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:LoggerTechnologyService Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): OECD-OPSI- Quality of Public Administrations - A toolbox for practicioners. https://oecd-opsi.org/toolkits/quality-of-public-administration-a-toolbox-for-practitioners/ Interoperability Saliency: Logger ABB is salient for semantic and technical interoperability due to it defines the mechanisms to manage messages from the applications to enhance their behavioural understanding in the execution or when unexpected behaviours occur. These mechanisms are based on open specifications for messaging representation and exchange. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/LoggerTechnologyService EIF Layer: TechnicalInfrastructure Definition: Containers Manager ABB is a Technology Service that implements the process of organizing, adding or replacing large numbers of software containers Source: Inspired in referent cloud service providers Source reference: Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/ContainersManagerTechnologyService LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:ContainersManagerTechnologyService Synonym: Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): OpenSHIFT is a secure and an enterprise-grade cloud-based container orchestration system with Kubernetes at the backend. It can be used both as a Red Hat Container Orchestration Engine and Platform-as-a-Service (PaaS). https://github.com/openshift/origin Interoperability Saliency: Containers Manager ABB is salient for technical interoperability due to its setting up the software tool to manage virtual public services and tools. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/ContainersManagerTechnologyService EIF Layer: TechnicalInfrastructure Definition: NoSQL Database Manager ABB is a Technology Service that enables the behaviour of a system that provides access to non-relational databases. Source: Inspired in the definition provided by relebant noSQL vendors Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/NoSQLDatabaseManagerTechnologyService LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:NoSQLDatabaseManagerTechnologyService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): NoSQL Manager by mongodb. User friendly interface and Shell power. Intuitive interface and high performance of the desktop application save time for beginners and professional database developers and administrators. https://www.mongodbmanager.com/ Interoperability Saliency: NoSQL Database Manager ABB is salient for semantic interoperability due to its implements mechanism to manipulate NoSQL databases and share data using common data exchange models (e.g. JSON) Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/NoSQLDatabaseManagerTechnologyService EIF Layer: TechnicalInfrastructure Definition: Router ABB is a Technology Service that enables the implementation of a component to connect multiple networks and directs traffic between them Source: ISO 35.110 Source reference: https://www.iso.org/ics/35.110/x/ Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/RouterTechnologyService LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:RouterTechnologyService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Turris Omnia Open Source Router, https://opensource.com/article/22/1/turris-omnia-open-source-router Interoperability Saliency: Router ABB is salient for technical interoperability due to it physically establishes the rules for distributing the information into a network. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/RouterTechnologyService EIF Layer: TechnicalInfrastructure Definition: Object Oriented Database Manager ABB is a Technology Service that implements the behaviour of a software system that applies concepts of object-oriented programming, and applies them to the management of persistent objects on behalf of multiple users, with capabilities for security, integrity, recovery and contention management Source: Gartner Source reference: https://www.gartner.com/en/information-technology/glossary/oodbms-object-oriented-database-management-system Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/Object-OrientedDatabaseManagerTechnologyService LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:Object-OrientedDatabaseManagerTechnologyService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): PostgreSQL is an open source object-relational database system that has an edge over other relational databases as the software supports user-defined objects and their behaviors including operators, data types, domains, and indexes. This makes the database software more flexible and robust. https://www.postgresql.org/ Interoperability Saliency: Object Oriented DatabaseManager ABB is salient for semantic interoperability because it implements data management using object-oriented specifications and their corresponding data representation to share the information with different public administration services. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/Object-OrientedDatabaseManagerTechnologyService EIF Layer: TechnicalInfrastructure Definition: Distributed File System is a Technology Service that implements the behaviour of a software tool that allows access to files from multiple computers in a distributed network Source: Inspired in Gartner Source reference: https://www.gartner.com/reviews/market/distributed-file-systems-and-object-storage Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/DistributedFileSystemTechnologyService LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:DistributedFileSystemTechnologyService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): MooseFS is a Fault-tolerant, Highly available, Highly performing, Scaling-out, Network distributed file system. It spreads data over several physical commodity servers, which are visible to the user as one virtual disk. It is POSIX compliant and acts like any other Unix-like file system supporting: -Hierarchical structure: Files and Folders, -File attributes, -Special files: Pipes, Sockets, Block and Character devices, -Symbolic and Hard links, -Security attributes and ACLs. https://moosefs.com/ Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/DistributedFileSystemTechnologyService EIF Layer: TechnicalInfrastructure Definition: Database Cache Manager ABB is a Technology Service that implements the behaviour of a software system that manages the caching of frequently accessed data in memory Source: Inspired in the definition provided by relebant database vendors Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/DatabaseCacheManagerTechnologyService LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:DatabaseCacheManagerTechnologyService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Redis, The open source, in-memory data store used by millions of developers as a database, cache, streaming engine, and message broker. https://redis.io/ Interoperability Saliency: Database Cache Manager ABB is salient for semantic interoperability due to implementing a mechanism to manage data in memory to provide to the public administration consumers efficiently and in a short time response. It also facilitates data sharing and reuse using common data exchange models and serialisations. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/DatabaseCacheManagerTechnologyService EIF Layer: TechnicalInfrastructure Definition: Remote Desktop ABB is a Technology Service that enables the procedures to grant users to access and control a computer or device from a remote location using a network connection Source: Inspired in Gartner Source reference: https://www.gartner.com/en/information-technology/glossary/remote-access Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/RemoteDesktopTechnologyService LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:RemoteDesktopTechnologyService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): PSI Remote Desktop Service from the European Open Science Cloud https://marketplace.eosc-portal.eu/services/remote-desktop-service?from_recommendation_panel=true&fromc=access-physical-einfrastructures Interoperability Saliency: Remote Desktop ABB is salient for technical interoperability because it refers to the sharing of a workspace to share or access public administration applications remotely. This contributes to establishing European public services with remote accessibility. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/RemoteDesktopTechnologyService EIF Layer: TechnicalInfrastructure Definition: Telemetry ABB is a Technology Service that enables the procedures to automatically measure and analyse information about public administration services and IT platforms to track performance and identify issues. Source: EEA Source reference: https://www.eea.europa.eu/help/glossary/gemet-environmental-thesaurus/telemetry Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/TelemetryTechnologyService LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:TelemetryTechnologyService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Telemetry is a clear example of use in computers integrated in spacecrafts. https://www.esa.int/Enabling_Support/Space_Engineering_Technology/Onboard_Computers_and_Data_Handling/Telemetry_Telecommand Interoperability Saliency: Telemetry is salient for semantic and technical interoperability because it sets up the mechanisms to monitor a specific ICT system to (i) collect behavioural information, and (ii) understand the ICT system's behaviour during its execution. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/TelemetryTechnologyService EIF Layer: TechnicalInfrastructure Definition: Containers Registry ABB is a Technology Service that enables the procedures to elaborate a repository of a collection of registries used to store and access container images Source: Redhat Source reference: https://www.redhat.com/en/topics/cloud-native-apps/what-is-a-container-registry Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/ContainerRegistryTechnologyService LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:ContainerRegistryTechnologyService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Project QUAY, Quay is a container image registry that enables you to build, organize, distribute, and deploy containers. Quay gives you security over your repositories with image vulnerability scanning and robust access controls. Project Quay provides a scalable open source platform to host container images across any size organization. https://www.projectquay.io/ Interoperability Saliency: Container Registry ABB is salient for semantic interoperability due to it establishing a catalogue of registries of virtual public services and tools to be deployed and executed. Additional information: Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/ContainerRegistryTechnologyService EIF Layer: TechnicalInfrastructure Definition: IaaS ABB is a Technology Service that enables the procedures to implement a standardized, highly automated offering in which computing resources owned by a service provider, complemented by storage and networking capabilities, are offered to customers on demand. Resources are scalable and elastic in near real-time and metered by use. Self-service interfaces, including an API and a graphical user interface (GUI), are exposed directly to customers. Resources may be single-tenant or multitenant and are hosted by the service provider or on-premises in a customer’s data centre. Source: Gartner Source reference: https://www.gartner.com/en/information-technology/glossary/infrastructure-as-a-service-iaas Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/IaaSTechnologyService LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:IaaSTechnologyService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): EBSI, the European Blockchain Service Infrastructure. lockchain Services Infrastructure (EBSI) aims to leverage the power of blockchain for the public good. EBSI is an initiative of the European Commission and the European Blockchain Partnership. what are databricks Interoperability Saliency: The IaaS ABB is salient for technical interoperability because it provides the needed infrastructure to store information and virtualize software tools related to public administration. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/IaaSTechnologyService EIF Layer: TechnicalInfrastructure Definition: Business Process Manager ABB is a Technology Service that implements the behaviour of coordinates the behavior of people, systems, information and things to produce business outcomes in support of a business strategy Source: Gartner Source reference: https://www.gartner.com/en/information-technology/glossary/business-process-management-bpm Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/BusinessProcessManagerTechnologyService LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:BusinessProcessManagerTechnologyService Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): UNDP- Business Process Re-engineering Manual. https://www.undp.org/sites/g/files/zskgke326/files/migration/uz/BPR-Manual_designed---Eng---final.pdf Interoperability Saliency: Business Process Manager ABB is salient for organizational interoperability due to it implements and defines business procedures related to public administration services. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/BusinessProcessManagerTechnologyService EIF Layer: TechnicalInfrastructure Definition: Active Directory ABB is a Technology Service that enables the procedures to work with interconnected, complex and different network resources in a unified manner Source: Inspired in CAMSS Source reference: https://joinup.ec.europa.eu/collection/common-assessment-method-standards-and-specifications-camss Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/ActiveDirectoryTechnologyService LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:ActiveDirectoryTechnologyService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): OpenLDAP highly flexible, scalable, and focused on providing core directory services to resources that leverage the LDAP protocol. https://www.openldap.org/ Interoperability Saliency: The Active Directory ABB is salient for technical interoperability because it is the store container about the public administration services and information that permit (i) establishing policies for the access and use of public services, (ii) deploying programs inside the public administration, and (iii) holistically manage software updates. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/ActiveDirectoryTechnologyService EIF Layer: TechnicalInfrastructure Definition: Firewall ABB is a technology Service that enables the implementation of a network security component that monitors and controls the incoming and outgoing network traffic based on predetermined security rules Source: Inspired in referent cloud service providers definitions Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/FirewallTechnologyService LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:FirewallTechnologyService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): pfSense® software is a free, open source customized distribution of FreeBSD specifically tailored for use as a firewall and router that is entirely managed via web interface. In addition to being a powerful, flexible firewalling and routing platform, it includes a long list of related features and a package system allowing further expandability without adding bloat and potential security vulnerabilities to the base distribution. https://www.pfsense.org/about-pfsense/ Interoperability Saliency: The Firewall ABB is salient for technical interoperability because it permits control of the traffic between the public administration and the different information providers and information consumers. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/FirewallTechnologyService EIF Layer: TechnicalInfrastructure Definition: Data Lake Storage ABB is a Technology Service that implements the behaviour of a storage repository that allows organizations to store large amounts of structured, semi-structured, and unstructured data at any scale Source: Inspired in Forbes Source reference: https://www.forbes.com/sites/ciocentral/2011/07/21/big-data-requires-a-big-new-architecture/?sh=5be8fb361157 Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/DataLakeStorageTechnologyService LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:DataLakeStorageTechnologyService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Smart Data Lake. https://smartdatalake.eu/ Interoperability Saliency: Data Lake storage ABB is salient for semantic and technical interoperability because it provides the data architecture to store and share multiple sources of data under a common framework. This ABB also provides FAIR data through the application of data curation pipelines that maximise the data quality returned to the public service consumers. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/DataLakeStorageTechnologyService EIF Layer: TechnicalInfrastructure Definition: Event Manager ABB is a Technology Service that implements the behaviour of collecting, analyzing, and responding to events or alerts generated by various digital platforms, including servers, applications, network devices, and security appliances Source: Inspired in the definition provided by relebant cloud service organizations. Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/EventManagerTechnologyService LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:EventManagerTechnologyService Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Apache Kafka (https://kafka.apache.org/) Interoperability Saliency: Event Manager ABB is salient for semantic and technical interoperability due to its establish mechanism to promote event and stream data sharing using existing open standards and commonly agreed metadata. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/EventManagerTechnologyService EIF Layer: TechnicalInfrastructure Definition: Load Balancer ABB is a Technology Service that enables the implementation of a component that distributes incoming network traffic across multiple servers or network resources Source: Inspired in referent cloud service providers definitions Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/LoadBalancerTechnologyService LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:LoadBalancerTechnologyService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): DIGIT/C Hosting Service - DIGIT/C offers a high availability and high performance hosting infrastructure that is being comprised, among other elements, of back-end web server instances and application servers for hosting and serving both static and dynamic sites. http://ec.europa.eu/ipg/build/infrastructure/index_en.htm Interoperability Saliency: The Load Balancer ABB is salient for technical interoperability because it provides the functionalities to maintain the traffic to the public administration digital services accordingly with a load that can permit their correct performance. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/LoadBalancerTechnologyService EIF Layer: TechnicalInfrastructure Definition: Business Intelligence ABB is a Technology Service that enables the procedure of collecting, storing, and analysing the data produced by the public administration to improve and optimise decisions and performance. Source: Inspired in Gartner Source reference: https://www.gartner.com/en/information-technology/glossary/business-intelligence-bi Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/BusinessIntelligenceTechnologyService LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:BusinessIntelligenceTechnologyService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Central banks increasingly need to use business intelligence (BI) systems to collect, manage and analyse data in order to inform policy decisions. This report presents the results of a survey conducted by the BIS’s Irving Fisher Committee on Central Bank Statistics (IFC) in 2019. The following link gives access to a report on the use of BI in Central Banks. https://www.bis.org/ifc/publ/ifc_report_bi_1910.pdf Interoperability Saliency: Business Intelligence ABB is salient for semantic interoperability because it provides visual and data understanding functionalities to be provided to the users in form of reports and other king of visual diagrams. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/BusinessIntelligenceTechnologyService EIF Layer: TechnicalInfrastructure Definition: Audit Manager ABB is a Technology Service that enables the procedures of managing audits and workflows, tracking audit progress, and ensuring compliance with regulations and standards Source: Inspired in the definition provided by relebant cloud service organizations. Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/AuditManagerTechnologyService LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:AuditManagerTechnologyService Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Design Principles for Data Spaces -Position Paper. https://design-principles-for-data-spaces.org/ Interoperability Saliency: Audit Manager ABB is salient for the technical interoperability due to it implements the rules to assess business workflows of public administration services to ensure compliance with the regulation and open standards. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/AuditManagerTechnologyService EIF Layer: TechnicalInfrastructure Definition: Streaming Server ABB is a Technology Service that implements the behaviour of specialised computer server designed to stream digital multimedia content to client devices over the Internet or a local network Source: Inspired in Gartner Source reference: https://www.gartner.com/en/information-technology/glossary/streaming Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/StreamingServerTechnologyService LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:StreamingServerTechnologyService Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Study of use Open Source Software in the Public Sector. http://softlibre.unizar.es/manuales/legal/oss-fact-sheet.pdf Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/StreamingServerTechnologyService EIF Layer: TechnicalInfrastructure Definition: Analytics ABB is a Technology service that enables the procedures of analysing a great amount of raw data to make conclusions about specific information. Source: Inspired in Data Act Source reference: https://digital-strategy.ec.europa.eu/en/policies/data-act Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/AnalyticsTechnologyService LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:AnalyticsTechnologyService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Europa Analytics is the corporate service that monitors and evaluates the effectiveness and efficiency of the European Commission's websites on Europa. https://commission.europa.eu/europa-analytics_en Interoperability Saliency: Analytics ABB is salient for technical and semantic interoperability in because it provides all functionalities to analyze huge amount of information by indicating inputs and outputs for the analytical services. Thus, semantic interoperability between analytical services can be provided as an interlink between processes and establish a common framework to map business processes in public administrations. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/AnalyticsTechnologyService EIF Layer: TechnicalInfrastructure Definition: GraphQL ABB is a Technology Service that implements the behaviour of a server-side runtime that execute queries using a type system you define for your data Source: GraphQL Source reference: https://graphql.org/learn/ Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/GraphQLServerTechnologyService LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:GraphQLServerTechnologyService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Github is using GraphQL Server and API to allow users retreive the required data without having additional information that is not relevant for its purpose. https://docs.github.com/es/graphql Interoperability Saliency: GraphQL Server ABB contributes to the semantic and technical interoperability because it set up the API that permits (i) access to the public administration information using semantics, (ii) exposes API following up common specifications related to GraphQL language. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/GraphQLServerTechnologyService EIF Layer: TechnicalInfrastructure Definition: Blockchain Ledger ABB is a Technology Service that enables the procedures to record, share, and synchronize transactions in the respective electronic ledger. Source: World Bank Source reference: https://www.worldbank.org/en/topic/financialsector/brief/blockchain-dlt Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/BlockchainLedgerTechnologyService LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:BlockchainLedgerTechnologyService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): OpenCHAIN is an open-source blockchain platform with distributed ledger technology. This blockchain company is suitable for organizations managing digital assets in secure and robust ways. Blockchain technology does not require fees for mining and the Bitcoin blockchain is significant for its immutability. https://www.openchainproject.org/ Interoperability Saliency: Blockchain Ledger ABB is salient for technical interoperability because it established the elements to publish public services and subsequent information securely across a trustworthy network. Additional information: Electronic Ledgers means the electronic master records of all contracts of the Sellers or the Issuer similar to and including the Contracts Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/BlockchainLedgerTechnologyService EIF Layer: TechnicalInfrastructure Definition: PaaS ABB is a Technology Service that enables the procedures for delivering application infrastructure (middleware) capabilities as a service. There are multiple types of PaaS (xPaaS), including, among many more, application platform as a service (aPaaS), integration PaaS (iPaaS), API management PaaS (apimPaaS), function PaaS (fPaaS), business analytics PaaS (baPaaS), IoT PaaS and database PaaS (dbPaaS). PaaS capability can be delivered as provider-managed or self-managed, multitenant or dedicated. Source: Gartner Source reference: https://www.gartner.com/en/information-technology/glossary/platform-as-a-service-paas Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/PaaSTechnologyService LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:PaaSTechnologyService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): OpenSHIFT is a secure and an enterprise-grade cloud-based container orchestration system with Kubernetes at the backend. It can be used both as a Red Hat Container Orchestration Engine and Platform-as-a-Service (PaaS). https://github.com/openshift/origin Interoperability Saliency: The PaaS ABB is salient for technical interoperability because it provides the mechanism to deploy and publish public administration services and make them accessible through the provided remote infrastructure. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/PaaSTechnologyService EIF Layer: TechnicalInfrastructure Definition: Data Catalog ABB is a Technology Service that enables the procedures of a centralised metadata repository to provide information about the data assets in a public administration Source: Inspired in JRC Source reference: https://data.jrc.ec.europa.eu/about Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/DataCatalogTechnologyService LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:DataCatalogTechnologyService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Jount Research Centre Data Catalogue. https://data.jrc.ec.europa.eu/ Interoperability Saliency: Data Catalog ABB is salient for semantic interoperability because it provides grouped datasets of information enhanced with metadata to promote their discovery, sharing and understanding for other digital services and public administrations Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/DataCatalogTechnologyService EIF Layer: TechnicalInfrastructure Definition: Federated Identity Provider ABB is a Technology Service that enables users to access multiple applications and services across different organizations or domains using a single set of credentials Source: Inpired in eIDAS Source reference: https://digital-strategy.ec.europa.eu/en/policies/eidas-regulation Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/FederatedIdentityProviderTechnologyService LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:FederatedIdentityProviderTechnologyService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Federated Identity can be achieved by implementing the OpenID Connect Federation specification. https://openid.net/specs/openid-connect-federation-1_0.html Interoperability Saliency: Federated Identity Provider ABB is salient for technical interoperability because it conforms to the network of identity provider systems to distribute the transference and identification of stakeholders to access and make use of public services. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/FederatedIdentityProviderTechnologyService EIF Layer: TechnicalInfrastructure Definition: Virtual Private Network ABB is a Technology Service that enables the procedures to implement a protected information system link utilizing tunnelling, security controls, and endpoint address translation giving the impression of a dedicated line Source: NIST Source reference: https://csrc.nist.gov/glossary/term/virtual_private_network Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/VirtualPrivateNetworkTechnologyService LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:VirtualPrivateNetworkTechnologyService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Virtual Private Network service for accessing European Commission servers out of the Commission. https://wikis.ec.europa.eu/display/WEBGUIDE/01.+Access+to+servers+from+outside+the+European+Commission Interoperability Saliency: Virtual Private Network ABB is salient for technical interoperability because it implements standard methods to build a secure network to exchange information in public administration Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/VirtualPrivateNetworkTechnologyService EIF Layer: TechnicalInfrastructure Definition: Relational Database Manager ABB is a Technology Service that implements the behaviour of a software system that provides access to and management of relational databases Source: Inspired in Gartner Source reference: https://www.gartner.com/en/information-technology/glossary/rdbms-relational-database-management-system Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/RelationalDatabaseManagerTechnologyService LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:RelationalDatabaseManagerTechnologyService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): MySQL manager, an SQL for MySQL. https://www.sqlmanager.net/products/mysql/manager Interoperability Saliency: Relational Database Manager ABB is salient for semantic interoperability because it establishes a common mechanism to query structured data and share the information using common data exchange models Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/RelationalDatabaseManagerTechnologyService EIF Layer: TechnicalInfrastructure Definition: Application Server ABB is a Technology Service that implements the behaviour of system software that resides between the operating system (OS) on one side, the external resources (such as a database management system [DBMS], communications and Internet services) on another side and the users’ applications on the third side. Source: Gartner Source reference: https://www.gartner.com/en/information-technology/glossary/application-server Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/ApplicationServerTechnologyService LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:ApplicationServerTechnologyService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): DIGIT/C Hosting Service - DIGIT/C offers a high availability and high performance hosting infrastructure that is being comprised, among other elements, of back-end web server instances and application servers for hosting and serving both static and dynamic sites. http://ec.europa.eu/ipg/build/infrastructure/index_en.htm Interoperability Saliency: Application Server ABB is salient for semantic and technical interoperability because it implements the mechanism to expose access to applications using metadata. This exposition of application contributes to the integration of legacy systems and siloed information to expose to the different public service consumers. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/ApplicationServerTechnologyService EIF Layer: TechnicalInfrastructure Definition: Lightweight Directory Access ABB is a Technology Service that enables compliance with an open, vendor-neutral, industry-standard application protocol for accessing and maintaining distributed directory information services over an Internet Protocol (IP) network. Source: CAMSS Source reference: https://joinup.ec.europa.eu/collection/common-assessment-method-standards-and-specifications-camss Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/LightweightDirectoryAccessProtocolTechnologyService LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:LightweightDirectoryAccessProtocolTechnologyService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Lightweight Directory Access Protocol can be implemented in multiple platforms or systems, allowing to integrating an organisatio'n LDAP-enabled identity management service to other platforms such as Drupal. https://www.drupal.org/docs/contributed-modules/lightweight-directory-access-protocol-ldap Interoperability Saliency: Lightweight Directory Access ABB is salient for technical and semantic interoperability because it provides the needed software mechanism and the LDAP data exchange model to manage user authentication, user provisioning and access to public services. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/LightweightDirectoryAccessProtocolTechnologyService EIF Layer: TechnicalInfrastructure Definition: Management Console ABB is a Technology Service that enables the procedures to elaborate a centralised interface to manage and monitor digital platforms. Source: Inspired in the definition provided by relebant cloud service organizations. Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/ManagementConsoleTechnologyService LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:ManagementConsoleTechnologyService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Open e-TrustEx. https://joinup.ec.europa.eu/collection/e-trustex/solution/open-e-trustex/about Interoperability Saliency: Management Console ABB is salient for technical interoperability due to it contributes to consolidating the management and monitoring of public digital services to ensure their availability according to the service level agreements established. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/ManagementConsoleTechnologyService EIF Layer: TechnicalInfrastructure Definition: PKI Certificate Manager ABB is a Technology Service that enables the procedures to issue, maintain and revoke public key certificates Source: NIST Source reference: https://csrc.nist.gov/glossary/term/public_key_infrastructure Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/PKICertificateManagerTechnologyService LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:PKICertificateManagerTechnologyService Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): eDelivery - PKI Service. https://ec.europa.eu/digital-building-blocks/wikis/display/DIGITAL/PKI+Service Interoperability Saliency: PKI Certificate Manager ABB is salient for technical interoperability because permits the public services to exchange information through the use of digital certificates that permit the accessibility to such service. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/PKICertificateManagerTechnologyService EIF Layer: TechnicalInfrastructure Definition: Gateway ABB is a Technology Service that enables the implementation of a component that converts information, data or other communications from one protocol or format to another Source: Gartner Source reference: https://www.gartner.com/en/information-technology/glossary/gateway Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/GatewayTechnologyService LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:GatewayTechnologyService Synonym: Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): The Single Digital Gateway from the European Commission is implemented via Your Europe Portal. This portal allows searching and exchanging information from businesses at the European and national level. information from EU and member states. https://europa.eu/youreurope/index_en.htm Interoperability Saliency: Gateway ABB is salient for technical interoperability because it physically transforms information, data and other communications from one protocol or format into another standard protocol format. Additional information: Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/GatewayTechnologyService EIF Layer: TechnicalInfrastructure Definition: Web Server ABB is a Technology Service that implements the behaviour of a type of server software that handles HTTP (Hypertext Transfer Protocol) requests sent by clients, typically web browsers, and delivers web content back to the client in response Source: Inspired in ISA2-EIF Source reference: https://eur-lex.europa.eu/resource.html?uri=cellar:2c2f2554-0faf-11e7-8a35-01aa75ed71a1.0017.02/DOC_1&format=PDF Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/WebServerTechnologyService LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:WebServerTechnologyService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): DIGIT/C Hosting Service - DIGIT/C offers a high availability and high performance hosting infrastructure that is being comprised, among other elements, of back-end web server instances and application servers for hosting and serving both static and dynamic sites. http://ec.europa.eu/ipg/build/infrastructure/index_en.htm Interoperability Saliency: Streaming Server is salient for semantic technical interoperability because it provides ICT systems to manage data streams related to public digital services. This ABB provides real-time interaction with the data following up streaming open specifications and metadata (if needed). Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/WebServerTechnologyService EIF Layer: TechnicalInfrastructure Definition: Databriks ABB is a Technology Service that enables the procedures of a collaborative workspace to process large amounts of public administration data Source: Inspired in Databriks Source reference: https://docs.databricks.com/introduction/index.html Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/DatabricksTechnologyService LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:DatabricksTechnologyService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): IOStack is an H2020 funded by the European Commission that implemented Databricks as the tool for processing large amounts of data. https://ec.europa.eu/research/participants/documents/downloadPublic?documentIds=080166e5ae65ba9a&appId=PPGMS Interoperability Saliency: Databriks ABB is salient for semantic interoperability because it permits to break of public administration siloes through the construction of shared spaces to process and analyse data from different sources and domains. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/DatabricksTechnologyService EIF Layer: TechnicalInfrastructure Definition: SaaS ABB is a Technology Service that enables the procedures for delivering software that is owned and managed remotely by one or more providers. The provider delivers software based on one set of common code and data definitions that is consumed in a one-to-many model by all contracted customers at any time on a pay-for-use basis or as a subscription based on use metrics. Source: Gartner Source reference: https://www.gartner.com/en/information-technology/glossary/software-as-a-service-saas Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/SaasTechnologyService LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:SaasTechnologyService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Drupal is content management software. It's used to make many of the websites and applications you use every day. Drupal has great standard features, like easy content authoring, reliable performance, and excellent security. But what sets it apart is its flexibility; modularity is one of its core principles. Its tools help you build the versatile, structured content that dynamic web experiences need. https://www.drupal.org/about Interoperability Saliency: The SaaS ABB is salient for organizational, semantic and technical and technical interoperability due to it provides the needed infrastructure to deliver public administration services on demand. Also, SaaS provides the functionalities of common data models and definitions to support the internal communication between software components. Finally, SaaS provides also the set up of business rules to ensure the correct performance of the software modules. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/SaasTechnologyService EIF Layer: TechnicalInfrastructure Definition: API Manager ABB is a Technology Service that implements the behaviour of safely and securely publish APIs, either internally or externally Source: Gartner Source reference: https://www.gartner.com/en/information-technology/glossary/api-management Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/APIManagerTechnologyService LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:APIManagerTechnologyService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): API Manager, WSO2 API Manager is a complete platform for building, integrating, and exposing your digital services as managed APIs in the cloud, on-premise, and hybrid architectures to drive your digital transformation strategy. https://apim.docs.wso2.com/en/latest/ Interoperability Saliency: API Manager ABB is salient for semantic interoperability due to its setting up the rules to share public administration digital services to facilitate their accessibility, discovery and sharing across platforms. These rules follow up existing standards and common practices in the API documentation and accessibility (Open APIs description). Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/APIManagerTechnologyService EIF Layer: TechnicalInfrastructure Definition: External Service ABB is a Technology Service that enables the procedures to offer services that are delivered by a third-party organization or vendor. Source: Inspired in Gartner Source reference: https://www.gartner.com/en/information-technology/glossary/esp-external-services-provider Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/ExternalServiceTechnologyService LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:ExternalServiceTechnologyService Interoperability Saliency: The External Service ABB is salient for organizational and semantic interoperability because it establishes the business rules and responsibilities to share digital services on the use of the public administration to complement the existing ones. This ABB also provides standardised data exchange models to share the information provided by external services. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/ExternalServiceTechnologyService EIF Layer: TechnicalInfrastructure Definition: Backup ABB is a is a Technology Service that implements the behaviour of a software tool that create a copy of important data or information to ensure that it can be recovered in case of data loss, corruption, or system failure Source: Gartner Source reference: https://www.gartner.com/en/information-technology/glossary/backup-server Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/BackupTechnologyService LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:BackupTechnologyService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Backup Archiving Recovery Open Sourced (bareos) is a set of computer programs that permits you (or the system administrator) to manage backup, recovery, and verification of computer data across a network of computers of different kinds. In technical terms, it is a network Client/Server based backup program. Bareos is relatively easy to use and efficient, while offering many advanced storage management features that make it easy to find and recover lost or damaged files. Due to its modular design, Bareos is scalable from small single computer systems to systems consisting of hundreds of computers located over a large network.. https://www.bareos.com/ Interoperability Saliency: Backup System ABB is salient for technical interoperability because it provides a secure mechanism to recover important information in case of unexpected behaviour of public administration services. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/BackupTechnologyService EIF Layer: TechnicalInfrastructure Definition: Computing Hosting, Networking, and Data Hosting Infrastructure Registry ABB are a Technology Service that enables the functionalities for i) hosting Interoperable European Solutions and ii) providing the necessary networks for operating these solutions. Source: ISA2 - EIA Action Source reference: https://digital-strategy.ec.europa.eu/en/news/isa2-interoperability-solutions-european-public-administrations-first-work-programme-adopted Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/ComputingHostingNetworkingAndDataHostingInfrastructureRegistryTechnologyService LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:ComputingHostingNetworkingAndDataHostingInfrastructureRegistryTechnologyService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB):DIGIT Hosting and Networking Infrastructure Service Interoperability Saliency: The Computing Hosting, Networking and Data Hosting Infrastructure Registry ABB is a key enabler interoperability enabler (*) for structural interoperability by enabling all the functionalities to host the Interoperable European Solutions (high availability and high-performance hosting infrastructure) and the network that can operate these solutions (a public and private network). Hosting and networking represent the lower level of the technical layer, but to be considered when designing an interoperable solution, as they can create interoperability barriers. Interoperability technical specifications need to be used at this level to ensure interoperability of the levels above. Interoperability Dimension: Structural IoP Viewpoint: Interoperability Security viewpoint Additional identifier: http://data.europa.eu/dr8/ComputingHostingNetworkingAndDataHostingInfrastructureRegistryTechnologyService EIF Layer: TechnicalInfrastructure Definition: Domain Name Service ABB is a Technology Service that enables the implementation of a directory which translates numeric IP addresses into Domain Names to identify users on the Internet Source: LAWINSIDER Source reference: https://www.lawinsider.com/dictionary/domain-name-service Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/DomainNameServiceTechnologyService LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:DomainNameServiceTechnologyService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Europe Registry, Europe Registry is a trusted domain expert with over twenty years experience in the domain industry. We have multiple ICANN Accreditations and provide domain registration for country code top level domains (ccTLDs). https://www.europeregistry.com/ Interoperability Saliency: Domain Name Service ABB is salient for semantic interoperability because it implements a catalogue of internet addresses associated with the corresponding names to facilitate accessibility to public administration services. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/DomainNameServiceTechnologyService EIF Layer: TechnicalInfrastructure Definition: Block Storage ABB is an Application Component that enables the behaviour of breaking data into separate pieces (blocks) and storing them with a unique identifier. Source: Inspired in referent cloud service providers Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/BlockStorageTechnologyService LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:BlockStorageTechnologyService Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Kibana at EU. https://big-data-test-infrastructure.ec.europa.eu/service-offering/kibana_en Interoperability Saliency: Block Storage ABB is salient for technical interoperability because it set up data storage and integration in fixed-sized blocks under a hierarchical infrastructure that permits ensuring their integrity through time. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/BlockStorageTechnologyService EIF Layer: TechnicalInfrastructure Definition: stributed Blockchain Network ABB is a Technology Service that enables the implementation procedures to manage tokens that may be utilised and/or exchanged, as communicated by the Company to the Token holders from time to time Source: World Bank Source reference: https://www.worldbank.org/en/topic/financialsector/brief/blockchain-dlt Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/DistributedBlockchainNetworkTechnologyService LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:DistributedBlockchainNetworkTechnologyService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Oasis Network, The Oasis Network is a Layer 1 decentralized blockchain network designed to be uniquely scalable, privacy-first and versatile. The Network has two main architectural components, the consensus layer and the ParaTime layer: 1. The consensus layer is a scalable, high-throughput, secure, proof-of-stake consensus run by a decentralized set of validator nodes; 2. The ParaTime layer hosts many parallel runtimes (ParaTimes), each representing a replicated compute environment with shared state. https://docs.oasis.io/general/oasis-network/ Interoperability Saliency: Distributed Blockchain Network ABB is salient for technical interoperability because it establishes the infrastructure to share information and also makes the information consistent under distributed data stores. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/DistributedBlockchainNetworkTechnologyService EIF Layer: TechnicalInfrastructure Definition: Serveless Orchestration ABB is a Technology Service that implements the behaviour of coordinating and managing individual functions are deployed as separate, independent units of code that can be executed in response to specific events or triggers. Source: inspired in RedHat Source reference: https://www.redhat.com/en/topics/cloud-native-apps/what-is-serverless Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/ServerlessOrchestratorTechnologyService LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:ServerlessOrchestratorTechnologyService Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Architecture of Orchestration for serverless computing. https://ec.europa.eu/research/participants/documents/downloadPublic?documentIds=080166e5d0f56561&appId=PPGMS Interoperability Saliency: Serverless Orchestrator ABB is salient for technical interoperability because it establishes the events and individual functions to combine information from legacy and public administrations service to respond to the applications and stakeholders that consume its information. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/ServerlessOrchestratorTechnologyService EIF Layer: TechnicalInfrastructure Definition: File storage ABB is a Technology Service that implements the behaviour of a software tool that refers to the process of storing and organizing digital files in a secure and efficient manner Source: Inspired in the definition provided by relebant database vendors Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/FileStorageTechnologyService LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:FileStorageTechnologyService Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): GARTNER- Distributed File Systems and Objects Storage Reviews and Ratings. https://www.gartner.com/reviews/market/distributed-file-systems-and-object-storage Interoperability Saliency: File Storage ABB is salient for technical interoperability because it set up the data integration mechanism based on different files. This kind of file storage permit also ensures data provenance of the information considering file modification and creation. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/FileStorageTechnologyService EIF Layer: TechnicalInfrastructure Definition: Graph Database manager ABB is a Technology Service that implements the behaviour of a software system that manages and manipulates data stores in the form of nodes, edges, and properties, which are represented as a graph Source: Inspired in the definition provided by relebant Graph database vendors Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/GraphDatabaseManagerTechnologyService LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:GraphDatabaseManagerTechnologyService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): neo4j Graph Database management. https://neo4j.com/docs/graph-data-science/current/management-ops/ Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/GraphDatabaseManagerTechnologyService EIF Layer: TechnicalInfrastructure Definition: Immutable Database Manager ABB is a Technology Service that enables the procedure to manage data that cannot be (or shouldn't be) deleted or modified. Source: ODBMS Source reference: https://www.odbms.org/2015/10/the-rise-of-immutable-data-stores/ Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/InmutableDatabaseManagerTechnologyService LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:InmutableDatabaseManagerTechnologyService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): immubd is a database written in Go, but unlike other databases, it is immutable: history is preserved and can't be changed without clients noticing. immudb can be used both as a key-value store, or as a relational database (SQL). immudb can be run as full database server with replicas or easily embedded as a lightweight database into application. https://docs.immudb.io/master/ Interoperability Saliency: Immutable Database Manager ABB is salient for technical interoperability because it establishes the mechanism to store information and also, manages that the stored information is cannot be deleted or modified. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/InmutableDatabaseManagerTechnologyService EIF Layer: TechnicalInfrastructure Definition: Identity provider ABB is a Technology Service that enables the authentication of users and provides them with a secure means of accessing online resources and applications Source: Inpired in eIDAS Source reference: https://digital-strategy.ec.europa.eu/en/policies/eidas-regulation Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/IdentityProviderTechnologyService LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:IdentityProviderTechnologyService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): EU Login is the European Commission's user authentication service. It allows authorised users to access a wide range of Commission web services. EU Login is the entry gate to sign in to different European Commission services and/or other systems. EU Login verifies your identity and allows recovering your personal settings, history and access rights in a secure way. You can sign in using social media accounts or the EU Login account. https://webgate.ec.europa.eu/cas/about.html Interoperability Saliency: Identity Provider ABB is salient for technical and semantic interoperability because it provides mechanisms to ensure the identification of stakeholders (organizations or individuals) across multiple platforms around Europe. Thus, it permits: (i) making interoperable identities across the public service platforms, and (ii) secure identification to the public services. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/IdentityProviderTechnologyService EIF Layer: TechnicalInfrastructure Definition: API Gateway ABB is a Technology Service that implements the behaviour of acting as a single entry point for multiple APIs (Application Programming Interfaces) Source: Inspired in Joinup Source reference: https://joinup.ec.europa.eu/collection/api4dt/about Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/APIGatewayTechnologyService LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:APIGatewayTechnologyService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): API Gateway Authentication Bundle. It authenticates requests from European Commission service API Gateway. https://joinup.ec.europa.eu/collection/ecphp/solution/api-gw-authentication-php/about Interoperability Saliency: API Gateway ABB is salient for semantic interoperability due to its setting up the rules to share multiple public administration digital services to facilitate their accessibility, discovery and sharing across platforms (catalogue of APIs). These rules follow up existing standards and common practices in the API documentation and accessibility (Open APIs description). Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/APIGatewayTechnologyService EIF Layer: TechnicalInfrastructure Definition: Enterprise Service Bus ABB is a Technology Service that enables integration between applications by acting as a centralized component to perform the transformation in data models, handle connectivity, perform message routing, convert communication protocols and manage the composition of multiple requests. Source: Gartner Source reference: https://www.gartner.com/en/documents/1405237 Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/EnterpriseServiceBusTechnologyService LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:EnterpriseServiceBusTechnologyService Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): eXTra Enterprise Service Bus (eESB), eESB is an Enterprise Service Bus for exchanging data between the institutes of the German pension insurance. To connect the services within one institute EJB-Technology is used. The communication with external partners and between the different institutes of the German pension insurance is based on SOAP-WebServices. As data structure for the general communication the eXTra-Standard is used to address the responsible service applications. https://joinup.ec.europa.eu/collection/egovernment/solution/extra-enterprise-service-bus-eesb/about Interoperability Saliency: Enterprise Service Bus ABB is salient for semantic and technical interoperability due to it ensuring (i) data sharing across different public service applications and infrastructures using specific enhanced datasets with metadata, and (ii) providing data sharing mechanism using open specifications and open data standards. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/EnterpriseServiceBusTechnologyService EIF Layer: TechnicalInfrastructure DEFINITION: Architecture Requirement ABB is a Requirement being formulated as an agreed normative statement of a To-Be European Public Service Source: European Commission, ISA Programme (https://ec.europa.eu/isa2/sites/default/files/eif_brochure_final.pdf) EXAMPLES: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Stating that "an online support system is required" is considered an architectural requirement for the design of software. Source:(https://www.brainkart.com/article/Functional-Requirements---Software-Architectures_11271/#:~:text=The%20following%20are%20examples%20of%20explicit%20architectural%20requirements%3A,Functionality%208%20Usability%209%20Reliability%20More%20items...%20) DEFINITION: Legal Interoperability Requirement ABB is a Requirement that must be met to help achieve legal interoperability. Source: Joinup (https://joinup.ec.europa.eu/sites/default/files/document/2019-06/High-level%20Interoperability%20Requirements%20Solution%20Architecture%20Template%20%28HL%20SAT%29%20Design%20Guidelines_0.pdf) EXAMPLES: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): European portals should be compliant with legal and legislative acts such as the General Data Protection Regulation Source: (https://ec.europa.eu/eusurvey/runner/SIQAT_v200?startQuiz=true&surveylanguage=EN) DEFINITION: Organisational Interoperability Requirement ABB is a Requirement that must be met to help achieve organisational interoperability. Source: Joinup (https://joinup.ec.europa.eu/sites/default/files/document/2019-06/High-level%20Interoperability%20Requirements%20Solution%20Architecture%20Template%20%28HL%20SAT%29%20Design%20Guidelines_0.pdf) EXAMPLES: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): European portals should be compliant with organisational agreements Source: (https://ec.europa.eu/eusurvey/runner/SIQAT_v200?startQuiz=true&surveylanguage=EN) DEFINITION: Technical Interoperability Requirement ABB is a Requirement that must be met to help achieve technical interoperability. Source: Joinup (https://joinup.ec.europa.eu/sites/default/files/document/2019-06/High-level%20Interoperability%20Requirements%20Solution%20Architecture%20Template%20%28HL%20SAT%29%20Design%20Guidelines_0.pdf) EXAMPLES: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): European portals should be compliant with technical agreements, technical specifications. Source: (https://ec.europa.eu/eusurvey/runner/SIQAT_v200?startQuiz=true&surveylanguage=EN) DEFINITION: Semantic Interoperability Requirement ABB is a Requirement that must be met to help achieve semantic interoperability. Source: Joinup (https://joinup.ec.europa.eu/sites/default/files/document/2019-06/High-level%20Interoperability%20Requirements%20Solution%20Architecture%20Template%20%28HL%20SAT%29%20Design%20Guidelines_0.pdf) EXAMPLES: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): European portals should be compliant with semantic interoperability agreements, semantic interoperability specifications. Source: (https://ec.europa.eu/eusurvey/runner/SIQAT_v200?startQuiz=true&surveylanguage=EN) Definition: Delegation of Powers Provisioning Digital Public Services ABB is an Assessment representing the extent to which the digital public service delivery is delegated to lower public administrative tiers or to private organisations acting on behalf of the public administration. Source: Scientific Foundations of Digital Governance and Transformation Source reference: https://books.google.gr/books?id=IB5iEAAAQBAJ&pg=PA298&lpg=PA298&dq=Delegation+of+Powers+Provisioning+Digital+Public+Services&source=bl&ots=jyuzPhj0Q8&sig=ACfU3U1-hD4udfrf3Ye_7Ywly0FATpCu6Q&hl=el&sa=X&ved=2ahUKEwjHhuyQ-KT3AhUEt6QKHTNbCCwQ6AF6BAgPEAM#v=onepage&q=Delegation%20of%20Powers%20Provisioning%20Digital%20Public%20Services&f=false Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/DelegationOfPowersProvisioningDigitalPublicServicesAssessment LOST view: Legal view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:DelegationOfPowersProvisioningDigitalPublicServicesAssessment Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): OECD Designing and Delivering public services in the digital age (https://goingdigital.oecd.org/data/notes/No22_ToolkitNote_DigitalGovernment.pdf) Interoperability Saliency: The Delegation of Powers provisioning Digital Public Services ABB is salient for the legal interoperability due to it enables (i) the delegation of powers to local authorities to implement rules and metrics to monitor the digital public services; and (ii) the establishment of rules to balance the digital public services consumption. Interoperability Dimension: Structural IoP Viewpoint: Highlevel viewpoint Additional identifier: http://data.europa.eu/dr8/DelegationOfPowersProvisioningDigitalPublicServicesAssessment EIF Layer: Legal Definition: The Granularity of Legral requirements ABB is an Assessment that refers to the degree to which laws and regulations are broken down into specific requirements and standards that must be met. Source: Scientific Foundations of Digital Governance and Transformation Source reference: https://books.google.gr/books?id=IB5iEAAAQBAJ&pg=PA298&lpg=PA298&dq=Delegation+of+Powers+Provisioning+Digital+Public+Services&source=bl&ots=jyuzPhj0Q8&sig=ACfU3U1-hD4udfrf3Ye_7Ywly0FATpCu6Q&hl=el&sa=X&ved=2ahUKEwjHhuyQ-KT3AhUEt6QKHTNbCCwQ6AF6BAgPEAM#v=onepage&q=Delegation%20of%20Powers%20Provisioning%20Digital%20Public%20Services&f=false Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/GranularityOfLegalRequirementsAssessment LOST view: Legal view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:GranularityOfLegalRequirementsAssessment Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Study of use Open Source Software in the Public Sector. http://softlibre.unizar.es/manuales/legal/oss-fact-sheet.pdf Interoperability Saliency: The Granularity on Legal Requirements ABB is salient for governance and legal interoperability because it sets the rules and requirements devoted to i) reuse and elaborate public sector digital services; ii) data sharing rules to enable the exchange of data across different countries. Interoperability Dimension: Structural IoP Viewpoint: Highlevel viewpoint Additional identifier: http://data.europa.eu/dr8/GranularityOfLegalRequirementsAssessment EIF Layer: Legal Definition: Digital Solution Assumption ABB is a Constraint that refers to the factor that limits the realization of the exchange and sharing of data across different platforms Source: ISA2-EIF Source reference: https://ec.europa.eu/isa2/eif_en/ LOST view: Enterprise Architecture Framework alignment guidelines view Identifier: http://data.europa.eu/dr8/DigitalSolutionAssumptionConstraint ABB name: eira:DigitalSolutionAssumptionConstraint EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2022-01-23 dct:identifier: http://data.europa.eu/dr8/DigitalSolutionAssumptionConstraint Definition: Interoperable Digital Public Service Implementation Orientation ABB is a Constraint that implements the approach that a digital public service owner has to follow to implement their digital public services. Source: European Interoperability Framework (EIF) Source reference: http://eur-lex.europa.eu/resource.html?uri=cellar:2c2f2554-0faf-11e7-8a35-01aa75ed71a1.0017.02/DOC_3&format=PDF Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/InteroperableDigitalPublicServiceImplementationOrientationConstraint LOST view: Organisational view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:InteroperableDigitalPublicServiceImplementationOrientationConstraint Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): The four implementation orientations identified in IDPSIO, integration, technology, governance, and legal (see the Joinup IDPSIO solution home page: https://joinup.ec.europa.eu/collection/european-interoperability-reference-architecture-eira/solution/egovera/release/v210). Interoperability Saliency: Interoperable Digital Public Service Implementation Orientation ABB is salient for governance interoperability because it supports digital public service owners in deciding the approach to follow to implement their digital public services. Additional information: Studying the implementation orientation facilitate Member States in understanding the implementation impacts on the interoperability and the functioning of the digital public services from different perspectives. Interoperability Dimension: Governance IoP Viewpoint: Highlevel viewpoint Additional identifier: http://data.europa.eu/dr8/InteroperableDigitalPublicServiceImplementationOrientationConstraint EIF Layer: Organisational Definition: Public Policy Constraint ABB is a Constraint that imposes one or more restrictions on the way the Public Policy operates or may be realized. Source: Based on policy-making literature (e.g., Theory of Policy Constraint: https://www.synchronix.com/toc_exploit_subordinate_elevate.htm) as well as the definition of what a constraint is according to Archimate language. Source reference: https://pubs.opengroup.org/architecture/archimate3-doc/chap06.html Synonym: Public Policy Restriction Additional information: Cfr. https://ec.europa.eu/commission/presscorner/detail/en/ip_22_4503 for more information on the Path to the Digital Decade. Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Transparency: EIF Transparency Principle refers to: 1. Enabling visibility inside the administrative environment of a public administration. This is about allowing other public administrations, citizens and businesses to view and understand administrative rules, processes, data, services and decision-making. 2. Ensuring availability of interfaces with internal information systems. Public administrations operate a large number of what are often heterogeneous and disparate information systems in support of their internal processes. Interoperability depends on ensuring the availability of interfaces to these systems and the data they handle. In turn, interoperability facilitates reuse of systems and data, and enables these to be integrated into larger systems. 3. Securing the right to the protection of personal data, by respecting the applicable legal framework for the large volumes of personal data of citizens, held and managed by Public administrations.(https://ec.europa.eu/isa2/sites/default/files/eif_brochure_final.pdf) eira:iopDimension: Governance IoP LOST view: High Level view eira:iopSaliency: The Public Policy Constraint ABB is salient for the governance interoperability because it imposes conditions on the implementation of the system (e.g., specific technology that is to be used), a restriction on the implementation process (e.g., time or budget constraints), or a restriction on the functioning of the system (e.g., legal constraints). Identifier: http://data.europa.eu/dr8/PublicPolicyConstraint ABB name: eira:PublicPolicyConstraint EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-10-1 dct:identifier: http://data.europa.eu/dr8/PublicPolicyConstraint Definition: Digital Solution Constraint ABB is a Constraint that refers to the factor that limits the realization of the exchange and sharing of data across different platforms Source: ISA2-EIF Source reference: https://ec.europa.eu/isa2/eif_en/ eira:iopDimension: Governance IoP LOST view: Enterprise Architecture Framework alignment guidelines view Identifier: http://data.europa.eu/dr8/DigitalSolutionConstraintConstraint ABB name: eira:DigitalSolutionConstraintConstraint EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2022-01-23 dct:identifier: http://data.europa.eu/dr8/DigitalSolutionConstraintConstraint Definition: Public Policy Context ABB is a Constraint that describes the background against which policy decisions are made, policy processes take place and stakeholders or actors engage with the policy. Source: Based on policy-making literature as well as the explanations provided by the European Commission when describing Public Policies. Source reference: https://onlinelibrary.wiley.com/doi/abs/10.1111/1468-0009.12026 Additional information: Public Policy Context is a specialisation of Public Policy Constraint. As such, Public Policy Context(s) provides the limits for the realisation of goals. In contrast to requirements, a Public Policy Constraint does not prescribe some intended functionality of the system to be realized but might impose restrictions on the implementation of the system (e.g., specific technology that is to be used, such as the usage of open source software), a restriction on the implementation process (e.g., time or budget constraints), or a restriction on the functioning of the system (e.g., legal constraints). Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): The European Cybersecurity Strategy has won a relevant role in the European IT environment since Ukraine's was started. Cybersecurity attacks have become a regular war method. Therefore, the context for the strength and increasing efforts by the Commission is this singular event. The following link illustrates the state of the art: Russia's war on Ukraine: Timeline of cyber-attacks. https://www.europarl.europa.eu/thinktank/en/document/EPRS_BRI(2022)733549 eira:iopDimension: Governance IoP LOST view: High Level view eira:iopSaliency: The Public Policy Context ABB  is salient for the governance interoperability because it provides further limits and specifications used for the implementing of legal instruments; e.g., for its in recitals of Regulations, Directives, Implementing Acts and other legal instruments. Identifier: http://data.europa.eu/dr8/PublicPolicyContextConstraint ABB name: eira:PublicPolicyContextConstraint EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-10-1 dct:identifier: http://data.europa.eu/dr8/PublicPolicyContextConstraint Definition: Means for Public Policy Objectives Convergence Assurance and Control ABB is a Constraint formalising the mechanisms that are to be used to assure union or uniformity regarding Public Policy Objectives. Source: Europarl Source reference: https://www.europarl.europa.eu/RegData/etudes/IDAN/2018/614502/IPOL_IDA(2018)614502_EN.pdf Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Policy Risk Management approaches and tools for public policy convergence assurance and control, as suggested in studies like the "Explaining Policy Convergence and Divergence through Policy Paradigm Shifts: A Comparative Analysis of Agricultural Risk Governance in OECD Countries" (https://www.tandfonline.com/doi/full/10.1080/13876988.2019.1674623) or in the abundant literature on Public Policy Convergence (see, for example, "Introduction: Cross-National Policy Convergence: Concepts, Approaches, and Explanatory Factors", https://www.researchgate.net/publication/30015252_Introduction_Cross-National_Policy_Convergence_Concepts_Approaches_and_Explanatory_Factors) eira:iopDimension: Governance IoP LOST view: OV-Data Spaces eira:iopSaliency: Means for Public Policy Objectives Convergence Assurance an Control ABB is relevant for the governance of the interoperability because it provides solution(s) to compare, analyse, measure and correct the gaps between what is actually being provided by the public digital services and what were the intended cross public policy objectives. Identifier: http://data.europa.eu/dr8/MeansForPublicPolicyObjectivesConvergenceAssuranceAndControlConstraint ABB name: eira:MeansForPublicPolicyObjectivesConvergenceAssuranceAndControlConstraint EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2022-01-13 dct:identifier: http://data.europa.eu/dr8/MeansForPublicPolicyObjectivesConvergenceAssuranceAndControlConstraint Definition: EIRA Dimension ABB is a Constraint that represents a factor that limits the realization of goals. Source: Archimate Source reference: https://pubs.opengroup.org/architecture/archimate3-doc/chap06.html Identifier: http://data.europa.eu/dr8/EIRADimensionConstraint eira:ID: http://data.europa.eu/dr8/EIRADimensionConstraint ABB name: eira:EIRADimensionConstraint Last modification: 2022-23-01 Definition: The Creation of Interoperable European Solutions Driver represents an external or internal condition that motivates the public organisation to define its goals and implement the changes necessary to create Digital Public Services. Source: ArchiMate Source reference: https://pubs.opengroup.org/architecture/archimate3-doc/index.html IoP Dimension: Structural IoP LOST view: Interoperability Motivation View Identifier: http://data.europa.eu/dr8/CreationOfInteroperableEuropeanSolutionsDriver eira:ID: http://data.europa.eu/dr8/CreationOfInteroperableEuropeanSolutionsDriver ABB name: eira:CreationOfInteroperableEuropeanSolutionsDriver DEFINITION: Achieve Semantic Interoperability ABB is a Goal. For the purpose of the EIF, interoperability is the ability of organisations to interact towards mutually beneficial goals, involving the sharing of information and knowledge between these organisations, through the business processes they support, by means of the exchange of data between their ICT systems. The interoperability model which is applicable to all digital public services and may also be considered as an integral element of the interoperability-by-design paradigm. It includes: four layers of interoperability: legal, organisational, semantic and technical. Semantic interoperability ensures that the precise format and meaning of exchanged data and information is preserved and understood throughout exchanges between parties, in other words ‘what is sent is what is understood’. In the EIF, semantic interoperability covers both semantic and syntactic aspects. Source: EIF (https://ec.europa.eu/isa2/sites/isa/files/eif_brochure_final.pdf) EXAMPLES: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Definition: Architecture Decision Record from where you should specialise the ADR SBBs regarding the Data Protection Measures Source: ISO/IEC/IEEE 42010:2022 Source reference: https://www.iso.org/standard/74393.html Additional information: Data Protection Measures refer to the set of policies, procedures, and technologies that are implemented to safeguard sensitive information from unauthorized access, use, disclosure, disruption, modification, or destruction. These measures are designed to ensure the confidentiality, integrity, and availability of data, and to comply with regulatory requirements and industry standards. Examples of data protection measures include encryption, access controls, firewalls, intrusion detection and prevention systems, backup and recovery systems, and disaster recovery plans. The selection and implementation of data protection measures depend on the nature and sensitivity of the data, the risks and threats to the data, and the cost and feasibility of the measures. Example: Data Protection Measures: Decision: Implementing data encryption at rest and in transit to protect sensitive data. Rationale: Data encryption helps safeguard sensitive information from unauthorized access, ensuring compliance with data protection regulations and industry best practices. LOST view: Digital Solution Architecture Decisions Catalogue view Identifier: http://data.europa.eu/dr8/egovera/DataProtectionMeasuresGoal EIRA traceability: eira:DigitalSolutionArchitectureDecisionGoal ABB name: egovera:DataProtectionMeasuresGoal EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-06-15 dct:identifier: ADR-20230515180947498 dct:title: Architecture Decision Record about Data Protection Measures eira:adr_context: The context explains why we need to make a decision. It also describes the alternatives along with the pros and cons. eira:adr_decision: The decision describes the justification for why the particular solution was accepted. It has more emphasis on the why rather than the how. eira:adr_status: [Proposed (under review)|Accepted (approved and ready for implementation)|Superseded (superseded by another decision)] eira:adr_consecuences: The consequences section contains information about the overall impact of an architectural decision. Every decision has trade-offs. That’s why it’s crucial to include the analysis to provide a clear picture. Definition: Architecture Decision Record from where you should specialise the ADR SBBs regarding the Security Testing Source: ISO/IEC/IEEE 42010:2022 Source reference: https://www.iso.org/standard/74393.html Additional information: Security testing is a critical aspect of IT architecture decision-making. It involves the evaluation of a system's security measures to identify vulnerabilities and potential threats. The goal of security testing is to ensure that the system is secure and protected from unauthorized access, data breaches, and other security risks. The testing process involves a range of techniques, including penetration testing, vulnerability scanning, and risk assessment. By conducting security testing, IT architects can identify weaknesses in the system and take steps to address them, thereby improving the overall security posture of the organization. Example: Security Testing: Decision: Conducting regular penetration testing and vulnerability assessments on the system. Rationale: Regular security testing helps identify and address vulnerabilities and weaknesses in the system, reducing the risk of exploitation by attackers. It ensures the ongoing security and resilience of the system. LOST view: Digital Solution Architecture Decisions Catalogue view Identifier: http://data.europa.eu/dr8/egovera/SecurityTestingGoal EIRA traceability: eira:DigitalSolutionArchitectureDecisionGoal ABB name: egovera:SecurityTestingGoal EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-06-15 dct:identifier: ADR-20230515180947450 dct:title: Architecture Decision Record about Security Testing eira:adr_context: The context explains why we need to make a decision. It also describes the alternatives along with the pros and cons. eira:adr_decision: The decision describes the justification for why the particular solution was accepted. It has more emphasis on the why rather than the how. eira:adr_status: [Proposed (under review)|Accepted (approved and ready for implementation)|Superseded (superseded by another decision)] eira:adr_consecuences: The consequences section contains information about the overall impact of an architectural decision. Every decision has trade-offs. That’s why it’s crucial to include the analysis to provide a clear picture. DEFINITION: Achieve Legal Interoperability ABB is a Goal. For the purpose of the EIF, interoperability is the ability of organisations to interact towards mutually beneficial goals, involving the sharing of information and knowledge between these organisations, through the business processes they support, by means of the exchange of data between their ICT systems. The interoperability model which is applicable to all digital public services and may also be considered as an integral element of the interoperability-by-design paradigm. It includes: four layers of interoperability: legal, organisational, semantic and technical. Legal interoperability is about ensuring that organisations operating under different legal frameworks, policies and strategies are able to work together. Source: EIF (https://ec.europa.eu/isa2/sites/isa/files/eif_brochure_final.pdf) EXAMPLES: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Definition: Architecture Decision Record from where you should specialise the ADR SBBs regarding the Service-Oriented Architecture Source: ISO/IEC/IEEE 42010:2022 Source reference: https://www.iso.org/standard/74393.html Additional information: SOA is an architecture that focuses on organizing software systems as a collection of reusable services. These services are well-defined, self-contained modules that communicate with each other using standardized interfaces. SOA promotes interoperability, flexibility, and reusability of services across multiple applications. Example: Title: Service-Oriented Architecture Decision Record (ADR) LOST view: Digital Solution Architecture Decisions Catalogue view Identifier: http://data.europa.eu/dr8/egovera/Service-OrientedArchitectureGoal EIRA traceability: eira:DigitalSolutionArchitectureDecisionGoal ABB name: egovera:Service-OrientedArchitectureGoal EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-08-20 dct:identifier: http://data.europa.eu/dr8/egovera/Service-OrientedArchitectureGoal dct:title: Architecture Decision Record about Service-Oriented Architecture eira:adr_context: The context explains why we need to make a decision. It also describes the alternatives along with the pros and cons. eira:adr_decision: The decision describes the justification for why the particular solution was accepted. It has more emphasis on the why rather than the how. eira:adr_status: [Proposed (under review)|Accepted (approved and ready for implementation)|Superseded (superseded by another decision)] eira:adr_consecuences: The consequences section contains information about the overall impact of an architectural decision. Every decision has trade-offs. That’s why it’s crucial to include the analysis to provide a clear picture. DEFINITION: Achieve Technical Interoperability ABB is a Goal. For the purpose of the EIF, interoperability is the ability of organisations to interact towards mutually beneficial goals, involving the sharing of information and knowledge between these organisations, through the business processes they support, by means of the exchange of data between their ICT systems. The interoperability model which is applicable to all digital public services and may also be considered as an integral element of the interoperability-by-design paradigm. It includes: four layers of interoperability: legal, organisational, semantic and technical. Technical interoperability covers the applications and infrastructures linking systems and services. Aspects of technical interoperability include interface specifications, interconnection services, data integration services, data presentation and exchange, and secure communication protocols Source: EIF (https://ec.europa.eu/isa2/sites/isa/files/eif_brochure_final.pdf) EXAMPLES: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Definition: Architecture Decision Record from where you should specialise the ADR SBBs regarding the Installability Source: ISO/IEC/IEEE 42010:2022 Source reference: https://www.iso.org/standard/74393.html Additional information: Installability in software architecture refers to the design and characteristics of a software system that enable easy and efficient installation, configuration, and deployment onto target environments. An installable software architecture aims to simplify the installation process for end-users or system administrators, reducing the time, effort, and potential errors involved in setting up and configuring the system. Example: Title: Installability Architecture Decision Record (ADR) LOST view: Digital Solution Architecture Decisions Catalogue view Identifier: http://data.europa.eu/dr8/egovera/InstallabilityGoal EIRA traceability: eira:DigitalSolutionArchitectureDecisionGoal ABB name: egovera:InstallabilityGoal EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-07-06 dct:identifier: ADR-20230606091024766 dct:title: Architecture Decision Record about Installability eira:adr_context: The context explains why we need to make a decision. It also describes the alternatives along with the pros and cons. eira:adr_decision: The decision describes the justification for why the particular solution was accepted. It has more emphasis on the why rather than the how. eira:adr_status: [Proposed (under review)|Accepted (approved and ready for implementation)|Superseded (superseded by another decision)] eira:adr_consecuences: The consequences section contains information about the overall impact of an architectural decision. Every decision has trade-offs. That’s why it’s crucial to include the analysis to provide a clear picture. Definition: Architecture Decision Record from where you should specialise the ADR SBBs regarding the Role-Based Access Control (RBAC) Source: ISO/IEC/IEEE 42010:2022 Source reference: https://www.iso.org/standard/74393.html Additional information: Role-Based Access Control (RBAC) is a concept in IT architecture that provides a method for controlling access to resources based on the roles of individual users within an organization. This approach is designed to simplify the process of managing access to sensitive data and systems by assigning permissions based on job responsibilities rather than individual identities. With RBAC, administrators can create roles that define specific access privileges and then assign those roles to users based on their job functions. This helps to ensure that users only have access to the resources they need to perform their duties, reducing the risk of unauthorized access and data breaches. RBAC is widely used in enterprise environments and is considered a best practice for access control in IT security. Example: Role-Based Access Control (RBAC): Decision: Implementing RBAC to enforce fine-grained access controls based on user roles and permissions. Rationale: RBAC provides a structured and manageable approach to access control, ensuring that users have appropriate privileges based on their roles within the system, minimizing the risk of unauthorized actions. LOST view: Digital Solution Architecture Decisions Catalogue view Identifier: http://data.europa.eu/dr8/egovera/Role-BasedAccessControlGoal EIRA traceability: eira:DigitalSolutionArchitectureDecisionGoal ABB name: egovera:Role-BasedAccessControlGoal EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-06-15 dct:identifier: ADR-20230515180947403 dct:title: Architecture Decision Record about Role-Based Access Control (RBAC) eira:adr_context: The context explains why we need to make a decision. It also describes the alternatives along with the pros and cons. eira:adr_decision: The decision describes the justification for why the particular solution was accepted. It has more emphasis on the why rather than the how. eira:adr_status: [Proposed (under review)|Accepted (approved and ready for implementation)|Superseded (superseded by another decision)] eira:adr_consecuences: The consequences section contains information about the overall impact of an architectural decision. Every decision has trade-offs. That’s why it’s crucial to include the analysis to provide a clear picture. Definition: An Architectural Decision Record (ADR) is a document that captures the key decisions made during the architectural design and development of a software system. It is used to record the rationale, alternatives considered, and trade-offs made during the decision-making process, as well as the context and implications of each decision. Source: Architectural Decision Records Source reference: https://adr.github.io/ IoP Dimension: Governance IoP LOST view: Interoperability Motivation View Identifier: http://data.europa.eu/dr8/DigitalSolutionArchitectureDecisionGoal eira:ID: http://data.europa.eu/dr8/DigitalSolutionArchitectureDecisionGoal EIRA concept: eira:ArchitectureBuildingBlock Last modification: 24-04-2023 dct:identifier: A unique increasing number and date that usually follows the ADR-nnnn pattern to help sort them from old to new (ADR-20230412180800). The format to use is ADR-[YYYYMMDDHHmmSS]. dct:title: The title contains a short phrase describing the architectural decisions. dct:description: The description contains a full description of the architectural decisions. adr:context: The context explains why we need to make a decision. It also describes the alternatives along with the pros and cons. adr:decision: The decision describes the justification for why the particular solution was accepted. It has more emphasis on the why rather than the how. adr:status: [Proposed (under review)|Accepted (approved and ready for implementation)|Superseded (superseded by another decision)] adr:consecuences: The consequences section contains information about the overall impact of an architectural decision. Every decision has trade-offs. That’s why it’s crucial to include the analysis to provide a clear picture. Definition: Architecture Decision Record from where you should specialise the ADR SBBs regarding the Application of Service Monitoring Tools Source: ISO/IEC/IEEE 42010:2022 Source reference: https://www.iso.org/standard/74393.html Additional information: The application of service monitoring tools is a decision in IT architecture that involves the use of software tools to monitor and manage the performance of IT services. These tools are designed to provide real-time visibility into the performance of IT systems, applications, and infrastructure, allowing IT teams to quickly identify and resolve issues before they impact end-users. Service monitoring tools typically include features such as performance monitoring, event management, and alerting, which enable IT teams to proactively manage and optimize IT services. By using these tools, IT teams can improve service availability, reduce downtime, and enhance the overall user experience. The decision to implement service monitoring tools requires careful consideration of factors such as the organization's IT infrastructure, the complexity of its IT services, and the level of support required. It also involves selecting the right tools that are compatible with the organization's existing IT systems and can provide the necessary level of visibility and control. Example: Network Optimization: Decision: Set-up a monitoring tool (like Prometheus or similar). Rationale: Since there will be multiple services deployed in the Operate First environment (ex. Jupyterhub, Argo, Superset, Observatorium, etc) distributed over various namespaces, we need to be able to monitor them. LOST view: Digital Solution Architecture Decisions Catalogue view Identifier: http://data.europa.eu/dr8/egovera/ApplicationOfServiceMonitoringToolsGoal EIRA traceability: eira:DigitalSolutionArchitectureDecisionGoal ABB name: egovera:ApplicationOfServiceMonitoringToolsGoal EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-06-15 dct:identifier: ADR-20230515180947825 dct:title: Architecture Decision Record about Application of Service Monitoring Tools eira:adr_context: The context explains why we need to make a decision. It also describes the alternatives along with the pros and cons. eira:adr_decision: The decision describes the justification for why the particular solution was accepted. It has more emphasis on the why rather than the how. eira:adr_status: [Proposed (under review)|Accepted (approved and ready for implementation)|Superseded (superseded by another decision)] eira:adr_consecuences: The consequences section contains information about the overall impact of an architectural decision. Every decision has trade-offs. That’s why it’s crucial to include the analysis to provide a clear picture. Definition: Architecture Decision Record from where you should specialise the ADR SBBs regarding the Coding Standards Source: ISO/IEC/IEEE 42010:2022 Source reference: https://www.iso.org/standard/74393.html Additional information: This ADR documents decisions regarding the coding standards and guidelines that developers should follow during software development. It includes decisions related to code formatting, naming conventions, and best practices to ensure consistency and improve code quality. Example: Title: Coding Standards Architecture Decision Record (ADR) LOST view: Digital Solution Architecture Decisions Catalogue view Identifier: http://data.europa.eu/dr8/egovera/CodingStandardsGoal EIRA traceability: eira:DigitalSolutionArchitectureDecisionGoal ABB name: egovera:CodingStandardsGoal EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-07-06 dct:identifier: ADR-20230606091024690 dct:title: Architecture Decision Record about Coding Standards eira:adr_context: The context explains why we need to make a decision. It also describes the alternatives along with the pros and cons. eira:adr_decision: The decision describes the justification for why the particular solution was accepted. It has more emphasis on the why rather than the how. eira:adr_status: [Proposed (under review)|Accepted (approved and ready for implementation)|Superseded (superseded by another decision)] eira:adr_consecuences: The consequences section contains information about the overall impact of an architectural decision. Every decision has trade-offs. That’s why it’s crucial to include the analysis to provide a clear picture. Definition: Architecture Decision Record from where you should specialise the ADR SBBs regarding the Data Exchange Deployment Source: ISO/IEC/IEEE 42010:2022 Source reference: https://www.iso.org/standard/74393.html Additional information: The Data Exchange Deployment ADR is a decision that refers to the process of establishing a system for exchanging data between different applications, systems, or organizations. It involves defining the data exchange requirements, selecting appropriate data exchange protocols, and implementing the necessary infrastructure to support the exchange of data. The goal of Data Exchange Deployment is to ensure that data is shared efficiently and securely, enabling organizations to make better decisions and improve their operations. This concept is particularly important in today's interconnected world, where data is generated and consumed by a wide range of applications and systems. Example: Decision: Data Exchange Management is operated by the Data Exchanger. Consequence: Capability assigned to Data Exchanger LOST view: Digital Solution Architecture Decisions Catalogue view Identifier: http://data.europa.eu/dr8/egovera/DataExchangeDeploymentGoal EIRA traceability: eira:DigitalSolutionArchitectureDecisionGoal ABB name: egovera:DataExchangeDeploymentGoal EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-06-15 dct:identifier: ADR-20230515180947856 dct:title: Architecture Decision Record about Data Exchange Deployment eira:adr_context: The context explains why we need to make a decision. It also describes the alternatives along with the pros and cons. eira:adr_decision: The decision describes the justification for why the particular solution was accepted. It has more emphasis on the why rather than the how. eira:adr_status: [Proposed (under review)|Accepted (approved and ready for implementation)|Superseded (superseded by another decision)] eira:adr_consecuences: The consequences section contains information about the overall impact of an architectural decision. Every decision has trade-offs. That’s why it’s crucial to include the analysis to provide a clear picture. Definition: Architecture Decision Record from where you should specialise the ADR SBBs regarding the Vertical Scaling Source: ISO/IEC/IEEE 42010:2022 Source reference: https://www.iso.org/standard/74393.html Additional information: Vertical scaling, also known as scaling up or scaling vertically, is a method of increasing the capacity and capabilities of a single server or machine by adding more resources to it. This is typically achieved by upgrading the hardware components, such as increasing the processing power, memory, storage capacity, or network bandwidth of the server. Example: Title: Vertical Scaling Architecture Decision Record (ADR) LOST view: Digital Solution Architecture Decisions Catalogue view Identifier: http://data.europa.eu/dr8/egovera/VerticalScalingGoal EIRA traceability: eira:DigitalSolutionArchitectureDecisionGoal ABB name: egovera:VerticalScalingGoal EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-07-06 dct:identifier: ADR-20230606091024769 dct:title: Architecture Decision Record about Vertical Scaling eira:adr_context: The context explains why we need to make a decision. It also describes the alternatives along with the pros and cons. eira:adr_decision: The decision describes the justification for why the particular solution was accepted. It has more emphasis on the why rather than the how. eira:adr_status: [Proposed (under review)|Accepted (approved and ready for implementation)|Superseded (superseded by another decision)] eira:adr_consecuences: The consequences section contains information about the overall impact of an architectural decision. Every decision has trade-offs. That’s why it’s crucial to include the analysis to provide a clear picture. Definition: Architecture Decision Record from where you should specialise the ADR SBBs regarding the Provide a Service Catalog Source: ISO/IEC/IEEE 42010:2022 Source reference: https://www.iso.org/standard/74393.html Additional information: The concept of Provide a Service Catalog in IT architecture decision-making involves creating a comprehensive list of all the services that an organization offers to its customers or clients. This catalog provides a clear and concise description of each service, including its features, benefits, and pricing. By having a service catalog, customers can easily find the services they need and understand what they are getting. It also helps organizations to manage their services more efficiently, prioritize their resources, and make informed decisions about service offerings. The service catalog can be made available online or in print, and it can be updated regularly to reflect changes in the organization's services. Example: Decision: Chosen option: "Backstage", because we don't want to reimplement the tooling, we want something opensource and Backstage is now a CNCF project. Rationale: As a transparent and open cloud we need a simple yet complete way of displaying services that are available on our platform, their current status, support path etc. LOST view: Digital Solution Architecture Decisions Catalogue view Identifier: http://data.europa.eu/dr8/egovera/ProvideAServiceCatalogGoal EIRA traceability: eira:DigitalSolutionArchitectureDecisionGoal ABB name: egovera:ProvideAServiceCatalogGoal EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-06-15 dct:identifier: ADR-20230515180947704 dct:title: Architecture Decision Record about Provide a Service Catalog eira:adr_context: The context explains why we need to make a decision. It also describes the alternatives along with the pros and cons. eira:adr_decision: The decision describes the justification for why the particular solution was accepted. It has more emphasis on the why rather than the how. eira:adr_status: [Proposed (under review)|Accepted (approved and ready for implementation)|Superseded (superseded by another decision)] eira:adr_consecuences: The consequences section contains information about the overall impact of an architectural decision. Every decision has trade-offs. That’s why it’s crucial to include the analysis to provide a clear picture. Definition: Architecture Decision Record from where you should specialise the ADR SBBs regarding the Application of Service Monitoring Tools Configuration Source: ISO/IEC/IEEE 42010:2022 Source reference: https://www.iso.org/standard/74393.html Additional information: The Application of Service Monitoring Tools Configuration concept refers to the process of configuring service monitoring tools to ensure that they can effectively monitor and manage the performance of IT services. This involves setting up the tools to collect data on key performance indicators (KPIs) such as response time, availability, and throughput, and configuring alerts and notifications to ensure that IT teams are alerted to any issues that arise. The goal of this concept is to enable IT teams to proactively identify and address issues before they impact end-users, thereby improving the overall performance and reliability of IT services. Example: Network Optimization: Decision: The GitHub alertmanager receiver can easily be configured and operated to function with Prometheus alerts. It automatically creates issues in GitHub repositories for any active alerts being fired, making it visible for any user to track All communication/updates/concerns related to the incident can be easily handled by adding comments in the issues created by the GitHub receiver Unlike Option 1, there is no additional cost involved There is no requirement for using JIRA/Slack for incident tracking, which are the only supported options in some of the tools listed in Option 2 (such as Dispatch and Response) In any case that such a requirement surfaces, we can use GitHub bots for different platforms such as GitHub for Slack and Google Chat to notify us of the issues immediately It is actively being maintained and supported compared to some of the tools in Option 1 (such as Cabot and OpenDuty) which lack community support Rationale: As we have multiple services/applications deployed and monitored in the Operate First environment (ex. Jupyterhub, Argo, Superset, Observatorium, Project Thoth, AICoE CI pipelines etc), we need to implement an incident reporting setup for handling outages/incidents related to these services. LOST view: Digital Solution Architecture Decisions Catalogue view Identifier: http://data.europa.eu/dr8/egovera/ApplicationOfServiceMonitoringToolsConfigurationGoal EIRA traceability: eira:DigitalSolutionArchitectureDecisionGoal ABB name: egovera:ApplicationOfServiceMonitoringToolsConfigurationGoal EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-06-15 dct:identifier: ADR-20230515180947662 dct:title: Architecture Decision Record about Application of Service Monitoring Tools Configuration eira:adr_context: The context explains why we need to make a decision. It also describes the alternatives along with the pros and cons. eira:adr_decision: The decision describes the justification for why the particular solution was accepted. It has more emphasis on the why rather than the how. eira:adr_status: [Proposed (under review)|Accepted (approved and ready for implementation)|Superseded (superseded by another decision)] eira:adr_consecuences: The consequences section contains information about the overall impact of an architectural decision. Every decision has trade-offs. That’s why it’s crucial to include the analysis to provide a clear picture. Definition: Architecture Decision Record from where you should specialise the ADR SBBs regarding the Disaster Recovery Plan Source: ISO Source reference: https://www.iso.org/standard/75106.html Additional information: A Disaster Recovery Plan (DRP) is a documented and structured approach that outlines the strategies, processes, and procedures to be followed in the event of a disaster or significant disruption that impacts an organization's IT infrastructure, systems, and data. The primary goal of a DRP is to minimize the impact of the disaster, recover critical systems and data, and restore normal operations as quickly and efficiently as possible. Example: Title: Disaster Recovery Plan Architecture Decision Record (ADR) LOST view: Digital Solution Architecture Decisions Catalogue view Identifier: http://data.europa.eu/dr8/egovera/DisasterRecoveryPlanGoal EIRA traceability: eira:DigitalSolutionArchitectureDecisionGoal ABB name: egovera:DisasterRecoveryPlanGoal EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-07-06 dct:identifier: ADR-20230606091024730 dct:title: Architecture Decision Record about Application of Disaster Recovery Plan eira:adr_context: The context explains why we need to make a decision. It also describes the alternatives along with the pros and cons. eira:adr_decision: The decision describes the justification for why the particular solution was accepted. It has more emphasis on the why rather than the how. eira:adr_status: [Proposed (under review)|Accepted (approved and ready for implementation)|Superseded (superseded by another decision)] eira:adr_consecuences: The consequences section contains information about the overall impact of an architectural decision. Every decision has trade-offs. That’s why it’s crucial to include the analysis to provide a clear picture. Definition: Architecture Decision Record from where you should specialise the ADR SBBs regarding the Adequacy Recognition Source: ISO/IEC/IEEE 42010:2022 Source reference: https://www.iso.org/standard/74393.html Additional information: Adequacy recognition refers to the degree to which the process of evaluating the suitability, completeness, and reliability of data or information within a software system is user-friendly, intuitive, and efficient. It encompasses the design and implementation of interfaces, workflows, and feedback mechanisms that enable users to easily and effectively perform adequacy recognition tasks. Example: Title: Adequacy Recognition Architecture Decision Record (ADR) LOST view: Digital Solution Architecture Decisions Catalogue view Identifier: http://data.europa.eu/dr8/egovera/AdequacyRecognitionGoal EIRA traceability: eira:DigitalSolutionArchitectureDecisionGoal ABB name: egovera:AdequacyRecognitionGoal EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-07-06 dct:identifier: ADR-20230606091024719 dct:title: Architecture Decision Record about Adequacy Recognition eira:adr_context: The context explains why we need to make a decision. It also describes the alternatives along with the pros and cons. eira:adr_decision: The decision describes the justification for why the particular solution was accepted. It has more emphasis on the why rather than the how. eira:adr_status: [Proposed (under review)|Accepted (approved and ready for implementation)|Superseded (superseded by another decision)] eira:adr_consecuences: The consequences section contains information about the overall impact of an architectural decision. Every decision has trade-offs. That’s why it’s crucial to include the analysis to provide a clear picture. Definition: Achieve Interoperability ABB is a Goal. For the purpose of the EIF, interoperability is the ability of organisations to interact towards mutually beneficial goals, involving the sharing of information and knowledge between these organisations, through the business processes they support, by means of the exchange of data between their ICT systems. Source: EIF Source reference: https://ec.europa.eu/isa2/sites/isa/files/eif_brochure_final.pdf Additional information: The interoperability model which is applicable to all digital public services and may also be considered as an integral element of the interoperability-by-design paradigm. It includes: four layers of interoperability: legal, organisational, semantic and technical. eira:iopDimension: Behavioral IoP LOST view: Enterprise Architecture Framework alignment guidelines view Identifier: http://data.europa.eu/dr8/AchieveInteroperabilityGoal ABB name: eira:AchieveInteroperabilityGoal EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-04-18 dct:identifier: http://data.europa.eu/dr8/AchieveInteroperabilityGoal Definition: Architecture Decision Record from where you should specialise the ADR SBBs regarding the Event-Driven Architecture Source: ISO/IEC/IEEE 42010:2022 Source reference: https://www.iso.org/standard/74393.html Additional information: In a monolithic architecture, the entire application is built as a single, self-contained unit. All components of the application are tightly coupled, and any changes or updates require modifying the entire system. This architecture is straightforward to develop and deploy but can become complex and difficult to scale or maintain as the application grows. Example: Title: Monolithic Architecture Decision Record (ADR) LOST view: Digital Solution Architecture Decisions Catalogue view Identifier: http://data.europa.eu/dr8/egovera/MonolithicArchitectureGoal EIRA traceability: eira:DigitalSolutionArchitectureDecisionGoal ABB name: egovera:MonolithicArchitectureGoal EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-07-06 dct:identifier: ADR-20230606091024763 dct:title: Architecture Decision Record about Monolithic Architecture eira:adr_context: The context explains why we need to make a decision. It also describes the alternatives along with the pros and cons. eira:adr_decision: The decision describes the justification for why the particular solution was accepted. It has more emphasis on the why rather than the how. eira:adr_status: [Proposed (under review)|Accepted (approved and ready for implementation)|Superseded (superseded by another decision)] eira:adr_consecuences: The consequences section contains information about the overall impact of an architectural decision. Every decision has trade-offs. That’s why it’s crucial to include the analysis to provide a clear picture. Definition: Architecture Decision Record from where you should specialise the ADR SBBs regarding the Cross-Border Semantic Data Management Source: ISO/IEC/IEEE 42010:2022 Source reference: https://www.iso.org/standard/74393.html Additional information: Cross-border Semantic Data Management is a concept that refers to the management of data across different countries or regions, with a focus on ensuring that the data is consistent and understandable across all borders. This involves the use of semantic technologies, which allow for the creation of a common language or vocabulary that can be used to describe data in a way that is easily understood by all parties involved. The goal of cross-border semantic data management is to improve the efficiency and effectiveness of data sharing and collaboration across different regions, while also ensuring that the data remains secure and protected. This concept is particularly important in today's globalized economy, where businesses and organizations often need to work together across borders to achieve their goals. Example: Decision: Data provider discovery and (semantic) data management capabilities are both operated by the same entity, with the role of Cross-Border Data Exchange. Consequence: Cross-Border Data Management is a new business role. LOST view: Digital Solution Architecture Decisions Catalogue view Identifier: http://data.europa.eu/dr8/egovera/Cross-BorderSemanticDataManagementGoal EIRA traceability: eira:DigitalSolutionArchitectureDecisionGoal ABB name: egovera:Cross-BorderSemanticDataManagementGoal EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-06-15 dct:identifier: ADR-20230515180947395 dct:title: Architecture Decision Record about Cross-Border Semantic Data Management eira:adr_context: The context explains why we need to make a decision. It also describes the alternatives along with the pros and cons. eira:adr_decision: The decision describes the justification for why the particular solution was accepted. It has more emphasis on the why rather than the how. eira:adr_status: [Proposed (under review)|Accepted (approved and ready for implementation)|Superseded (superseded by another decision)] eira:adr_consecuences: The consequences section contains information about the overall impact of an architectural decision. Every decision has trade-offs. That’s why it’s crucial to include the analysis to provide a clear picture. Definition: Architecture Decision Record from where you should specialise the ADR SBBs regarding the Serveless Architecture Source: ISO/IEC/IEEE 42010:2022 Source reference: https://www.iso.org/standard/74393.html Additional information: Serverless architecture, also known as Function-as-a-Service (FaaS), allows developers to focus on writing and deploying individual functions or microservices without managing the underlying infrastructure. Functions are triggered by events and run in ephemeral containers managed by a cloud provider. This architecture eliminates the need for provisioning or managing servers, enabling scalability and cost optimization. Example: Title: Serverless Architecture Decision Record (ADR) LOST view: Digital Solution Architecture Decisions Catalogue view Identifier: http://data.europa.eu/dr8/egovera/ServelessArchitectureGoal EIRA traceability: eira:DigitalSolutionArchitectureDecisionGoal ABB name: egovera:ServelessArchitectureGoal EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-07-06 dct:identifier: ADR-20230606091024695 dct:title: Architecture Decision Record about Serveless Architecture eira:adr_context: The context explains why we need to make a decision. It also describes the alternatives along with the pros and cons. eira:adr_decision: The decision describes the justification for why the particular solution was accepted. It has more emphasis on the why rather than the how. eira:adr_status: [Proposed (under review)|Accepted (approved and ready for implementation)|Superseded (superseded by another decision)] eira:adr_consecuences: The consequences section contains information about the overall impact of an architectural decision. Every decision has trade-offs. That’s why it’s crucial to include the analysis to provide a clear picture. Definition: Architecture Decision Record from where you should specialise the ADR SBBs regarding the UserInterface Source: ISO/IEC/IEEE 42010:2022 Source reference: https://www.iso.org/standard/74393.html Additional information: the user interface (UI) refers to the visual and interactive elements of a software system that allow users to interact with and control the system. It encompasses the design and presentation of screens, menus, buttons, forms, and other visual components that users engage with to perform tasks and access information within the system. Example: Title: User Interface Architecture Decision Record (ADR) LOST view: Digital Solution Architecture Decisions Catalogue view Identifier: http://data.europa.eu/dr8/egovera/UserInterfaceGoal EIRA traceability: eira:DigitalSolutionArchitectureDecisionGoal ABB name: egovera:UserInterfaceGoal EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-07-06 dct:identifier: ADR-20230606091024717 dct:title: Architecture Decision Record about UserInterface eira:adr_context: The context explains why we need to make a decision. It also describes the alternatives along with the pros and cons. eira:adr_decision: The decision describes the justification for why the particular solution was accepted. It has more emphasis on the why rather than the how. eira:adr_status: [Proposed (under review)|Accepted (approved and ready for implementation)|Superseded (superseded by another decision)] eira:adr_consecuences: The consequences section contains information about the overall impact of an architectural decision. Every decision has trade-offs. That’s why it’s crucial to include the analysis to provide a clear picture. Definition: Architecture Decision Record from where you should specialise the ADR SBBs regarding the Data Subscription Deployment Source: ISO/IEC/IEEE 42010:2022 Source reference: https://www.iso.org/standard/74393.html Additional information: The Data Subscription Deployment ADR is a decision made in IT architecture that involves the deployment of data subscriptions to enable real-time data access and analysis. This concept involves the use of data subscriptions to provide a continuous stream of data to applications, which can be used to make informed decisions in real-time. The deployment of data subscriptions can be done through various methods, including API integration, webhooks, and other data integration tools. This concept is particularly useful in industries such as finance, healthcare, and retail, where real-time data analysis is critical for decision-making. The Data Subscription Deployment concept can help organizations to improve their operational efficiency, reduce costs, and enhance customer experience by providing real-time insights into their business operations. Example: Decision: The Data Exchanger operates the Data Consumer Data Subscription capability Consequence: -- LOST view: Digital Solution Architecture Decisions Catalogue view Identifier: http://data.europa.eu/dr8/egovera/DataSubscriptionDeploymentGoal EIRA traceability: eira:DigitalSolutionArchitectureDecisionGoal ABB name: egovera:DataSubscriptionDeploymentGoal EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-06-15 dct:identifier: ADR-20230515180947764 dct:title: Architecture Decision Record about Data Subscription Deployment eira:adr_context: The context explains why we need to make a decision. It also describes the alternatives along with the pros and cons. eira:adr_decision: The decision describes the justification for why the particular solution was accepted. It has more emphasis on the why rather than the how. eira:adr_status: [Proposed (under review)|Accepted (approved and ready for implementation)|Superseded (superseded by another decision)] eira:adr_consecuences: The consequences section contains information about the overall impact of an architectural decision. Every decision has trade-offs. That’s why it’s crucial to include the analysis to provide a clear picture. Definition: Architecture Decision Record from where you should specialise the ADR SBBs regarding the Access Control Policy Source: ISO/IEC/IEEE 42010:2022 Source reference: https://www.iso.org/standard/74393.html Additional information: Access Control Policy is a critical concept in IT architecture that defines the rules and guidelines for controlling access to resources and data within an organization's network. It outlines the procedures and protocols that must be followed to ensure that only authorized users can access sensitive information and resources. The policy includes guidelines for user authentication, authorization, and access management, and it helps organizations to maintain the confidentiality, integrity, and availability of their data. The Access Control Policy is a crucial component of any IT security program, and it is essential for protecting against unauthorized access, data breaches, and cyber attacks. Example: Access Control Policies: Decision: Enforcing role-based access control (RBAC) and implementing strict access control policies for government systems. Rationale: RBAC provides a structured approach to managing user access based on predefined roles and responsibilities, reducing the risk of unauthorized access to sensitive information. LOST view: Digital Solution Architecture Decisions Catalogue view Identifier: http://data.europa.eu/dr8/egovera/AccessControlPolicyGoal EIRA traceability: eira:DigitalSolutionArchitectureDecisionGoal ABB name: egovera:AccessControlPolicyGoal EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-06-15 dct:identifier: ADR-20230515180947653 dct:title: Architecture Decision Record about Access Control Policy eira:adr_context: The context explains why we need to make a decision. It also describes the alternatives along with the pros and cons. eira:adr_decision: The decision describes the justification for why the particular solution was accepted. It has more emphasis on the why rather than the how. eira:adr_status: [Proposed (under review)|Accepted (approved and ready for implementation)|Superseded (superseded by another decision)] eira:adr_consecuences: The consequences section contains information about the overall impact of an architectural decision. Every decision has trade-offs. That’s why it’s crucial to include the analysis to provide a clear picture. Definition: Architecture Decision Record from where you should specialise the ADR SBBs regarding the Cross-Border Identification Business Source: ISO/IEC/IEEE 42010:2022 Source reference: https://www.iso.org/standard/74393.html Additional information: The Cross-Border Identification Business concept refers to the process of identifying individuals across different countries or regions. This is particularly important in industries such as finance, healthcare, and travel, where individuals may need to be identified and verified across borders. The IT architecture decision for this concept involves selecting the appropriate technologies and systems to enable secure and efficient cross-border identification, such as biometric identification, digital identity verification, and blockchain-based identity management systems. The decision also involves considering regulatory and legal requirements for cross-border identification, as well as privacy and data protection concerns. Example: Rationale: As a transparent and open cloud we need a simple yet complete way of displaying services that are available on our platform, their current status, support path etc. LOST view: Digital Solution Architecture Decisions Catalogue view Identifier: http://data.europa.eu/dr8/egovera/Cross-BorderIdentificationBusinessGoal EIRA traceability: eira:DigitalSolutionArchitectureDecisionGoal ABB name: egovera:Cross-BorderIdentificationBusinessGoal EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-06-15 dct:identifier: ADR-20230515180947478 dct:title: Architecture Decision Record about Cross-Border Identification Business eira:adr_context: The context explains why we need to make a decision. It also describes the alternatives along with the pros and cons. eira:adr_decision: The decision describes the justification for why the particular solution was accepted. It has more emphasis on the why rather than the how. eira:adr_status: [Proposed (under review)|Accepted (approved and ready for implementation)|Superseded (superseded by another decision)] eira:adr_consecuences: The consequences section contains information about the overall impact of an architectural decision. Every decision has trade-offs. That’s why it’s crucial to include the analysis to provide a clear picture. Definition: Architecture Decision Record from where you should specialise the ADR SBBs regarding the Continous Security Monitoring Source: ISO/IEC/IEEE 42010:2022 Source reference: https://www.iso.org/standard/74393.html Additional information: Continuous Security Monitoring is a concept in IT architecture that involves the continuous monitoring of an organization's IT infrastructure to detect and respond to security threats in real-time. This approach involves the use of automated tools and processes to monitor network traffic, system logs, and other data sources for signs of suspicious activity. The goal of continuous security monitoring is to identify potential security incidents as early as possible, so that they can be addressed before they can cause significant damage to the organization. This approach is becoming increasingly important as the number and complexity of security threats continue to grow, and as organizations become more reliant on technology to support their operations. Example: Continuous Security Monitoring: Decision: Implementing security monitoring tools and processes to continuously monitor and detect security incidents and vulnerabilities. Rationale: Continuous security monitoring helps identify and respond to security threats promptly, reducing the risk of unauthorized access, data breaches, or service disruptions. LOST view: Digital Solution Architecture Decisions Catalogue view Identifier: http://data.europa.eu/dr8/egovera/ContinousSecurityMonitoringGoal EIRA traceability: eira:DigitalSolutionArchitectureDecisionGoal ABB name: egovera:ContinousSecurityMonitoringGoal EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-06-15 dct:identifier: ADR-20230515180947683 dct:title: Architecture Decision Record about Continous Security Monitoring eira:adr_context: The context explains why we need to make a decision. It also describes the alternatives along with the pros and cons. eira:adr_decision: The decision describes the justification for why the particular solution was accepted. It has more emphasis on the why rather than the how. eira:adr_status: [Proposed (under review)|Accepted (approved and ready for implementation)|Superseded (superseded by another decision)] eira:adr_consecuences: The consequences section contains information about the overall impact of an architectural decision. Every decision has trade-offs. That’s why it’s crucial to include the analysis to provide a clear picture. Definition: Architecture Decision Record from where you should specialise the ADR SBBs regarding the Asynchronous Procesing Source: ISO/IEC/IEEE 42010:2022 Source reference: https://www.iso.org/standard/74393.html Additional information: Asynchronous Processing is a concept in IT architecture that involves executing tasks or processes independently of each other, without waiting for the completion of one task before starting another. This approach allows for greater efficiency and scalability, as multiple tasks can be executed simultaneously without causing delays or bottlenecks. Asynchronous processing is commonly used in web applications, where multiple users may be accessing the same system at the same time, and in distributed systems, where tasks may be spread across multiple servers or nodes. It is also used in event-driven architectures, where processes are triggered by specific events or messages. Overall, asynchronous processing is a key component of modern IT architectures, enabling faster, more efficient, and more scalable systems. Example: Decision: Integrating Apache Kafka and Apache Spark for processing large volumes of data in near real-time. Rationale: Kafka allows for the ingestion of high-volume data streams, while Spark provides a distributed processing framework for performing complex analytics and transformations on the data. LOST view: Digital Solution Architecture Decisions Catalogue view Identifier: http://data.europa.eu/dr8/egovera/AsynchronousProcesingGoal EIRA traceability: eira:DigitalSolutionArchitectureDecisionGoal ABB name: egovera:AsynchronousProcesingGoal EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-06-15 dct:identifier: ADR-20230515180947673 dct:title: Architecture Decision Record about Asynchronous Procesing eira:adr_context: The context explains why we need to make a decision. It also describes the alternatives along with the pros and cons. eira:adr_decision: The decision describes the justification for why the particular solution was accepted. It has more emphasis on the why rather than the how. eira:adr_status: [Proposed (under review)|Accepted (approved and ready for implementation)|Superseded (superseded by another decision)] eira:adr_consecuences: The consequences section contains information about the overall impact of an architectural decision. Every decision has trade-offs. That’s why it’s crucial to include the analysis to provide a clear picture. Definition: Architecture Decision Record from where you should specialise the ADR SBBs regarding the Documentation Source: ISO/IEC/IEEE 42010:2022 Source reference: https://www.iso.org/standard/74393.html Additional information: This ADR documents decisions regarding the documentation practices for the software system. It includes decisions on the types of documentation to be maintained (e.g., system architecture, API documentation, user guides), tools to be used for documentation, and guidelines for keeping documentation up to date. Example: Title: Documentation Architecture Decision Record (ADR) LOST view: Digital Solution Architecture Decisions Catalogue view Identifier: http://data.europa.eu/dr8/egovera/DocumentationGoal EIRA traceability: eira:DigitalSolutionArchitectureDecisionGoal ABB name: egovera:DocumentationGoal EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-07-06 dct:identifier: ADR-20230606091024761 dct:title: Architecture Decision Record about Documentation eira:adr_context: The context explains why we need to make a decision. It also describes the alternatives along with the pros and cons. eira:adr_decision: The decision describes the justification for why the particular solution was accepted. It has more emphasis on the why rather than the how. eira:adr_status: [Proposed (under review)|Accepted (approved and ready for implementation)|Superseded (superseded by another decision)] eira:adr_consecuences: The consequences section contains information about the overall impact of an architectural decision. Every decision has trade-offs. That’s why it’s crucial to include the analysis to provide a clear picture. Definition: Architecture Decision Record from where you should specialise the ADR SBBs regarding the Managing Self-Description Schemas in the Federated Catalogue Source: ISO/IEC/IEEE 42010:2022 Source reference: https://www.iso.org/standard/74393.html Additional information: The concept of Managing Self-description Schemas in the Federated Catalogue involves the creation and management of metadata that describes the data and services available in a federated environment. This metadata is used to enable discovery, understanding, and use of the data and services by users and applications. The self-description schemas provide a standardized way of describing the data and services, which makes it easier for users to find and use them. The federated catalogue is a central repository that stores the metadata and provides a search interface for users to discover the data and services. Effective management of self-description schemas in the federated catalogue is essential for ensuring that the data and services are discoverable, understandable, and usable by users and applications. Example: Decision: Self-Descriptions refer to one or several schemas via a "isA" relation. Every schema consists of classes and classes define attributes and relations to other Self-Descriptions. Only attributes from a class can be used for the Self-Descriptions. The Self-Description classes form an extensible inheritance hierarchy. For example geo-location for some Nodes. The Self-Description classes are versioned according to the Semantic Versioning conventions. GAIA-X provides and maintains a set of core Self-Description classes. The schema hierarchy can be extended with specialized classes, for example for a domain-specific ecosystem. GAIA-X defines requirements and processes to accept and distribute new Self-Description classes and updates thereof. - Option 1: Central repo by the GAIA-X Foundation for schemas - Option 2: Ecosystems / private catalogues can have additional schema sources RDF and SHACL are selected as technologies for schema description and enforcement. - RDF: Data model "behind" JSON-LD - SHACL: Validation of RDF against a schema independently from the serialization technology Rationale: For the purpose of validating Self-Descriptions, the Federated Catalogue needs to know the Schema to validate against. Gaia-X develops an extensible hierarchy of Schemas that define the terms used in Self-Descriptions. Some Schemas are standardized by the Gaia-X AISBL and must be supported by any Catalogue, but it should be possible to create additional ones specific to an application domain, an Ecosystem, Participants in it, or Assets offered by these Participants. Schemas have the same format as Self-Descriptions, i.e., they are graphs in the RDF data model, serialized as JSON-LD. A Schema may define terms (classes, their attributes, and their relationships to other classes) in an Ontology. If it does, it must also define Shapes to validate instances of the Ontology against. A Schema may also introduce a Controlled Vocabulary of attribute values intended to be reused. LOST view: Digital Solution Architecture Decisions Catalogue view Identifier: http://data.europa.eu/dr8/egovera/ManagingSelf-DescriptionSchemasInTheFederatedCatalogueGoal EIRA traceability: eira:DigitalSolutionArchitectureDecisionGoal ABB name: egovera:ManagingSelf-DescriptionSchemasInTheFederatedCatalogueGoal EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-06-15 dct:identifier: ADR-20230515180947835 dct:title: Architecture Decision Record about Managing Self-Description Schemas in the Federated Catalogue eira:adr_context: The context explains why we need to make a decision. It also describes the alternatives along with the pros and cons. eira:adr_decision: The decision describes the justification for why the particular solution was accepted. It has more emphasis on the why rather than the how. eira:adr_status: [Proposed (under review)|Accepted (approved and ready for implementation)|Superseded (superseded by another decision)] eira:adr_consecuences: The consequences section contains information about the overall impact of an architectural decision. Every decision has trade-offs. That’s why it’s crucial to include the analysis to provide a clear picture. Definition: Architecture Decision Record from where you should specialise the ADR SBBs regarding the API Design Source: ISO/IEC/IEEE 42010:2022 Source reference: https://www.iso.org/standard/74393.html Additional information: API design is a crucial aspect of IT architecture decision-making, as it determines how different software systems and applications communicate with each other. A well-designed API can improve the efficiency and effectiveness of software development, as it allows developers to easily integrate different systems and functionalities. On the other hand, a poorly designed API can lead to compatibility issues, security vulnerabilities, and other problems that can hinder the development process. Therefore, IT architects must carefully consider the design of APIs when making decisions about software development and integration. This includes factors such as the format and structure of the API, the security measures in place, and the ease of use for developers. Example: One example of the application of the Directive 2014/24/EU is in the procurement of construction services for a new public building. The directive requires that the procurement process be open, transparent, and non-discriminatory, with equal opportunities for all potential bidders. The contracting authority must publish a notice of the procurement in the Official Journal of the European Union, and provide all relevant information to interested parties. The directive also requires that the contracting authority evaluate bids based on objective criteria, and award the contract to the most economically advantageous tender. This ensures that public funds are used efficiently and effectively, and that the public receives high-quality services at a fair price. LOST view: Digital Solution Architecture Decisions Catalogue view Identifier: http://data.europa.eu/dr8/egovera/APIDesignGoal EIRA traceability: eira:DigitalSolutionArchitectureDecisionGoal ABB name: egovera:APIDesignGoal EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-06-15 dct:identifier: ADR-20230515180947613 dct:title: Architecture Decision Record about API Design eira:adr_context: The context explains why we need to make a decision. It also describes the alternatives along with the pros and cons. eira:adr_decision: The decision describes the justification for why the particular solution was accepted. It has more emphasis on the why rather than the how. eira:adr_status: [Proposed (under review)|Accepted (approved and ready for implementation)|Superseded (superseded by another decision)] eira:adr_consecuences: The consequences section contains information about the overall impact of an architectural decision. Every decision has trade-offs. That’s why it’s crucial to include the analysis to provide a clear picture. Definition: Architecture Decision Record from where you should specialise the ADR SBBs regarding the Integration Thrid-Party Systems Source: ISO/IEC/IEEE 42010:2022 Source reference: https://www.iso.org/standard/74393.html Additional information: Integration of third-party systems is a decision that involves the integration of external systems with the organization's existing IT infrastructure. This decision is essential to ensure that the organization's systems can communicate and share data with external systems, such as vendors, partners, and customers. The integration of third-party systems can improve the efficiency of business processes, reduce costs, and enhance the overall customer experience. However, it also requires careful planning and consideration of security, data privacy, and compliance requirements. The IT architecture team must evaluate the compatibility of the third-party systems with the existing infrastructure, assess the risks associated with the integration, and develop a robust integration strategy that aligns with the organization's business goals and objectives. Example: Integration with Third-Party Systems: Decision: Integrating the software system with popular customer relationship management (CRM) platforms. Rationale: Integrating with widely used CRM systems allows for seamless data exchange, better customer insights, and improved customer relationship management for the organization. LOST view: Digital Solution Architecture Decisions Catalogue view Identifier: http://data.europa.eu/dr8/egovera/IntegrationThrid-PartySystemsGoal EIRA traceability: eira:DigitalSolutionArchitectureDecisionGoal ABB name: egovera:IntegrationThrid-PartySystemsGoal EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-06-15 dct:identifier: ADR-20230515180947744 dct:title: Architecture Decision Record about Integration Thrid-Party Systems eira:adr_context: The context explains why we need to make a decision. It also describes the alternatives along with the pros and cons. eira:adr_decision: The decision describes the justification for why the particular solution was accepted. It has more emphasis on the why rather than the how. eira:adr_status: [Proposed (under review)|Accepted (approved and ready for implementation)|Superseded (superseded by another decision)] eira:adr_consecuences: The consequences section contains information about the overall impact of an architectural decision. Every decision has trade-offs. That’s why it’s crucial to include the analysis to provide a clear picture. Definition: Architecture Decision Record from where you should specialise the ADR SBBs regarding the Authentication Mechanism Source: ISO/IEC/IEEE 42010:2022 Source reference: https://www.iso.org/standard/74393.html Additional information: Authentication Mechanism is a crucial concept in IT architecture that refers to the process of verifying the identity of a user or system before granting access to resources or services. It involves the use of various methods such as passwords, biometric identification, smart cards, and tokens to ensure that only authorized users can access sensitive information or perform critical operations. The choice of authentication mechanism depends on the level of security required, the complexity of the system, and the user experience. A well-designed authentication mechanism can prevent unauthorized access, protect against cyber threats, and enhance the overall security of the IT infrastructure. Example: Authentication Mechanism: Decision: Implementing multi-factor authentication (MFA) using time-based one-time passwords (TOTP). Rationale: MFA adds an extra layer of security by requiring users to provide a second form of authentication, reducing the risk of unauthorized access even if credentials are compromised. TOTP is a widely supported and secure method for generating one-time passwords. LOST view: Digital Solution Architecture Decisions Catalogue view Identifier: http://data.europa.eu/dr8/egovera/AuthenticationMechanismGoal EIRA traceability: eira:DigitalSolutionArchitectureDecisionGoal ABB name: egovera:AuthenticationMechanismGoal EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-06-15 dct:identifier: ADR-20230515180947643 dct:title: Architecture Decision Record about Authentication Mechanism eira:adr_context: The context explains why we need to make a decision. It also describes the alternatives along with the pros and cons. eira:adr_decision: The decision describes the justification for why the particular solution was accepted. It has more emphasis on the why rather than the how. eira:adr_status: [Proposed (under review)|Accepted (approved and ready for implementation)|Superseded (superseded by another decision)] eira:adr_consecuences: The consequences section contains information about the overall impact of an architectural decision. Every decision has trade-offs. That’s why it’s crucial to include the analysis to provide a clear picture. Definition: Architecture Decision Record from where you should specialise the ADR SBBs regarding the Cloud-Native Architecture Source: ISO/IEC/IEEE 42010:2022 Source reference: https://www.iso.org/standard/74393.html Additional information: Cloud-native architecture is designed specifically for cloud environments, leveraging cloud computing capabilities and services. It emphasizes scalability, fault tolerance, and the use of containerization and orchestration tools like Docker and Kubernetes. Cloud-native applications are typically built using microservices and take advantage of cloud services such as storage, databases, and messaging queues. Example: Title: Cloud-Native Architecture Decision Record (ADR) LOST view: Digital Solution Architecture Decisions Catalogue view Identifier: http://data.europa.eu/dr8/egovera/Cloud-NativeArchitectureGoal EIRA traceability: eira:DigitalSolutionArchitectureDecisionGoal ABB name: egovera:Cloud-NativeArchitectureGoal EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-08-20 dct:identifier: http://data.europa.eu/dr8/egovera/Cloud-NativeArchitectureGoal dct:title: Architecture Decision Record about Cloud-Native Architecture eira:adr_context: The context explains why we need to make a decision. It also describes the alternatives along with the pros and cons. eira:adr_decision: The decision describes the justification for why the particular solution was accepted. It has more emphasis on the why rather than the how. eira:adr_status: [Proposed (under review)|Accepted (approved and ready for implementation)|Superseded (superseded by another decision)] eira:adr_consecuences: The consequences section contains information about the overall impact of an architectural decision. Every decision has trade-offs. That’s why it’s crucial to include the analysis to provide a clear picture. Definition: Digital Agenda ABB is a Goal that describes all the measures required or planned in a systematic way to support public policy in adopting the digital transformation. Source: Inspired on the contents of the EU Digital Agenda Source reference: https://www.europarl.europa.eu/factsheets/en/sheet/64/digital-agenda-for-europe Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/DigitalAgendaGoal LOST view: Organisational view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:DigitalAgendaGoal Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): The Digital Agenda for Europe. See https://www.europarl.europa.eu/factsheets/en/sheet/64/digital-agenda-for-europe. The widespread, rapid and extensive development of digital service platforms, as well as debates on public data spaces and new technologies such as artificial intelligence, affect all areas of our society. Many new ways to communicate, shop or access information online have been integrated into our daily lives and are constantly evolving. The European digital agenda for the decade 2020-2030 addresses these issues by focusing on creating secure digital spaces and services, creating a level playing field in digital markets with large platforms and strengthening Europe’s digital sovereignty, while contributing to the European goal of climate neutrality by 2050. Interoperability Saliency: The Digital Agenda ABB is salient for governance interoperability since it establishes the main goals and priorities that the digital public services are expected to support (e.g., the overall aim of the Digital Agenda is to deliver sustainable economic and social benefits from a digital single market based on fast and ultra-fast internet and interoperable applications). Additional information: Do not confuse Digital Agenda with Digitalisation Roadmap. An Agenda focuses on goals and priorities, e.g. protecting citizens and freedoms, developing a strong and vibrant economic base, building a climate-neutral, green, fair and social Europe, promoting European interests and values on the global stage, etc. A Roadmap focuses on the actions and deadlines that need to be executed to realise the Agenda. Interoperability Dimension: Governance IoP Viewpoint: Interoperability Governance viewpoint Additional identifier: http://data.europa.eu/dr8/DigitalAgendaGoal EIF Layer: Organisational Definition: Architecture Decision Record from where you should specialise the ADR SBBs regarding the Security Incident Response Source: ISO/IEC/IEEE 42010:2022 Source reference: https://www.iso.org/standard/74393.html Additional information: The Security Incident Response concept involves the development of a comprehensive plan to detect, respond to, and recover from security incidents that may occur within an organization's information systems. The plan should include procedures for identifying and assessing potential threats, as well as protocols for containing and mitigating the impact of any incidents that do occur. The goal of the Security Incident Response concept is to minimize the risk of data loss, system downtime, and other negative consequences that can result from security breaches. Effective implementation of this concept requires ongoing monitoring and testing of security measures, as well as regular training and awareness programs for employees. Example: Security Incident Response: Decision: Establishing an incident response plan to handle security breaches and incidents. Rationale: Having a well-defined incident response plan enables a quick and coordinated response to security incidents, minimizing potential damage, and facilitating the recovery and restoration of normal operations. LOST view: Digital Solution Architecture Decisions Catalogue view Identifier: http://data.europa.eu/dr8/egovera/SecurityIncidentResponseGoal EIRA traceability: eira:DigitalSolutionArchitectureDecisionGoal ABB name: egovera:SecurityIncidentResponseGoal EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-06-15 dct:identifier: ADR-20230515180947632 dct:title: Architecture Decision Record about Security Incident Response eira:adr_context: The context explains why we need to make a decision. It also describes the alternatives along with the pros and cons. eira:adr_decision: The decision describes the justification for why the particular solution was accepted. It has more emphasis on the why rather than the how. eira:adr_status: [Proposed (under review)|Accepted (approved and ready for implementation)|Superseded (superseded by another decision)] eira:adr_consecuences: The consequences section contains information about the overall impact of an architectural decision. Every decision has trade-offs. That’s why it’s crucial to include the analysis to provide a clear picture. Definition: Architecture Decision Record from where you should specialise the ADR SBBs regarding the Microservices Architecture Source: ISO/IEC/IEEE 42010:2022 Source reference: https://www.iso.org/standard/74393.html Additional information: Microservices architecture decomposes an application into smaller, loosely coupled services. Each service is responsible for a specific functionality and can be developed, deployed, and scaled independently. Services communicate with each other through lightweight APIs or messaging protocols. This architecture enables flexibility, scalability, and easier maintenance, but it introduces complexities in managing distributed systems. Example: Title: Microservices Architecture Decision Record (ADR) LOST view: Digital Solution Architecture Decisions Catalogue view Identifier: http://data.europa.eu/dr8/egovera/MicroserviceArchitectureGoal EIRA traceability: eira:DigitalSolutionArchitectureDecisionGoal ABB name: egovera:MicroserviceArchitectureGoal EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-08-20 dct:identifier: http://data.europa.eu/dr8/egovera/MicroserviceArchitectureGoal dct:title: Architecture Decision Record about Microservices Architecture eira:adr_context: The context explains why we need to make a decision. It also describes the alternatives along with the pros and cons. eira:adr_decision: The decision describes the justification for why the particular solution was accepted. It has more emphasis on the why rather than the how. eira:adr_status: [Proposed (under review)|Accepted (approved and ready for implementation)|Superseded (superseded by another decision)] eira:adr_consecuences: The consequences section contains information about the overall impact of an architectural decision. Every decision has trade-offs. That’s why it’s crucial to include the analysis to provide a clear picture. Definition: Architecture Decision Record from where you should specialise the ADR SBBs regarding the Containerization and Orchestration Source: ISO/IEC/IEEE 42010:2022 Source reference: https://www.iso.org/standard/74393.html Additional information: Containerization and orchestration are two concepts that are closely related to each other in the field of IT architecture. Containerization refers to the process of packaging an application and its dependencies into a single container that can be easily deployed across different environments. On the other hand, orchestration refers to the process of managing and coordinating multiple containers that are running in a distributed environment. This involves tasks such as scaling containers up or down, monitoring their health, and ensuring that they are communicating with each other correctly. Example: Containerization and Orchestration: Decision: Using containerization technologies, such as Docker, and container orchestration platforms, such as Kubernetes, for scalable deployment and management of system components. Rationale: Containerization provides a lightweight and consistent deployment mechanism, while orchestration platforms enable efficient management, scaling, and load balancing of containerized services. LOST view: Digital Solution Architecture Decisions Catalogue view Identifier: http://data.europa.eu/dr8/egovera/ContainerizationAndOrchestrationGoal EIRA traceability: eira:DigitalSolutionArchitectureDecisionGoal ABB name: egovera:ContainerizationAndOrchestrationGoal EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-06-15 dct:identifier: ADR-20230515180947565 dct:title: Architecture Decision Record about Containerization and Orchestration eira:adr_context: The context explains why we need to make a decision. It also describes the alternatives along with the pros and cons. eira:adr_decision: The decision describes the justification for why the particular solution was accepted. It has more emphasis on the why rather than the how. eira:adr_status: [Proposed (under review)|Accepted (approved and ready for implementation)|Superseded (superseded by another decision)] eira:adr_consecuences: The consequences section contains information about the overall impact of an architectural decision. Every decision has trade-offs. That’s why it’s crucial to include the analysis to provide a clear picture. Definition: Architecture Decision Record from where you should specialise the ADR SBBs regarding the Provisioning Capability Publication Source: ISO/IEC/IEEE 42010:2022 Source reference: https://www.iso.org/standard/74393.html Additional information: The Provisioning Capability Publication ADR is a part of IT architecture decision-making process that involves the publication of information about the provisioning capabilities of a system or application. This information can include details about the resources available, such as storage, memory, and processing power, as well as information about the system's performance and availability. The goal of this ADR is to provide users with the information they need to make informed decisions about how to use the system or application, and to ensure that the system is being used in the most efficient and effective way possible. By publishing this information, IT teams can also identify areas where improvements can be made to the system or application and make changes to optimize its performance. Example: Decision: The Data Provider has the capability to publish to the Data Exchanger its capabilities to provision Data. Consequence: New capability: Provisioning Capability Publication, part of Provisioning Capability Management LOST view: Digital Solution Architecture Decisions Catalogue view Identifier: http://data.europa.eu/dr8/egovera/ProvisioningCapabilityPublicationGoal EIRA traceability: eira:DigitalSolutionArchitectureDecisionGoal ABB name: egovera:ProvisioningCapabilityPublicationGoal EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-06-15 dct:identifier: ADR-20230515180947526 dct:title: Architecture Decision Record about Provisioning Capability Publication eira:adr_context: The context explains why we need to make a decision. It also describes the alternatives along with the pros and cons. eira:adr_decision: The decision describes the justification for why the particular solution was accepted. It has more emphasis on the why rather than the how. eira:adr_status: [Proposed (under review)|Accepted (approved and ready for implementation)|Superseded (superseded by another decision)] eira:adr_consecuences: The consequences section contains information about the overall impact of an architectural decision. Every decision has trade-offs. That’s why it’s crucial to include the analysis to provide a clear picture. Definition: Architecture Decision Record from where you should specialise the ADR SBBs regarding the Operability Source: ISO/IEC/IEEE 42010:2022 Source reference: https://www.iso.org/standard/74393.html Additional information: operability refers to the ease with which users can operate and interact with a software system to achieve their desired goals efficiently and effectively. It focuses on designing interfaces, workflows, and interactions that facilitate user understanding, control, and seamless navigation within the system. Example: Title: Operability Architecture Decision Record (ADR) LOST view: Digital Solution Architecture Decisions Catalogue view Identifier: http://data.europa.eu/dr8/egovera/OperabilityGoal EIRA traceability: eira:DigitalSolutionArchitectureDecisionGoal ABB name: egovera:OperabilityGoal EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-07-06 dct:identifier: ADR-20230606091024733 dct:title: Architecture Decision Record about Operability eira:adr_context: The context explains why we need to make a decision. It also describes the alternatives along with the pros and cons. eira:adr_decision: The decision describes the justification for why the particular solution was accepted. It has more emphasis on the why rather than the how. eira:adr_status: [Proposed (under review)|Accepted (approved and ready for implementation)|Superseded (superseded by another decision)] eira:adr_consecuences: The consequences section contains information about the overall impact of an architectural decision. Every decision has trade-offs. That’s why it’s crucial to include the analysis to provide a clear picture. Definition: Architecture Decision Record from where you should specialise the ADR SBBs regarding the Data Notification Deployment Source: ISO/IEC/IEEE 42010:2022 Source reference: https://www.iso.org/standard/74393.html Additional information: The Data Notification Deployment ADR is a decision made in IT architecture that involves the deployment of notifications related to data. This concept is used to ensure that users are informed about changes or updates to data that they are interested in. The notifications can be sent via email, SMS, or other communication channels. The purpose of this concept is to improve data management and ensure that users are aware of any changes that may affect their work. This concept is particularly important in organizations that deal with large amounts of data and have many users accessing that data. By deploying data notifications, organizations can improve data security, reduce errors, and increase productivity. Example: Decision: Data Notification capability is operated by the Data Exchanger (shared resources). Consequence: Data Subscription required LOST view: Digital Solution Architecture Decisions Catalogue view Identifier: http://data.europa.eu/dr8/egovera/DataNotificationDeploymentGoal EIRA traceability: eira:DigitalSolutionArchitectureDecisionGoal ABB name: egovera:DataNotificationDeploymentGoal EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-06-15 dct:identifier: ADR-20230515180947459 dct:title: Architecture Decision Record about Data Notification Deployment eira:adr_context: The context explains why we need to make a decision. It also describes the alternatives along with the pros and cons. eira:adr_decision: The decision describes the justification for why the particular solution was accepted. It has more emphasis on the why rather than the how. eira:adr_status: [Proposed (under review)|Accepted (approved and ready for implementation)|Superseded (superseded by another decision)] eira:adr_consecuences: The consequences section contains information about the overall impact of an architectural decision. Every decision has trade-offs. That’s why it’s crucial to include the analysis to provide a clear picture. Definition: Architecture Decision Record from where you should specialise the ADR SBBs regarding the Compliance Monitoring and Auditing Source: ISO/IEC/IEEE 42010:2022 Source reference: https://www.iso.org/standard/74393.html Additional information: Compliance monitoring and auditing is a concept in IT architecture that ensures that an organization's IT systems and processes comply with relevant laws, regulations, and industry standards. This concept involves the continuous monitoring of IT systems and processes to identify any potential compliance issues and the implementation of corrective actions to address them. Compliance monitoring and auditing also involves regular audits to assess the effectiveness of an organization's compliance program and identify areas for improvement. By implementing a robust compliance monitoring and auditing program, organizations can ensure that they are operating within legal and regulatory boundaries, protecting their reputation, and avoiding costly fines and penalties. Example: Compliance Monitoring and Auditing: Decision: Implementing mechanisms for continuous compliance monitoring, internal auditing, and vulnerability assessments. Rationale: Regular monitoring, auditing, and vulnerability assessments help identify compliance gaps, ensure ongoing adherence to regulations, and proactively address potential security risks. LOST view: Digital Solution Architecture Decisions Catalogue view Identifier: http://data.europa.eu/dr8/egovera/ComplianceMonitoringAndAuditingGoal EIRA traceability: eira:DigitalSolutionArchitectureDecisionGoal ABB name: egovera:ComplianceMonitoringAndAuditingGoal EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-06-15 dct:identifier: ADR-20230515180947604 dct:title: Architecture Decision Record about Compliance Monitoring and Auditing eira:adr_context: The context explains why we need to make a decision. It also describes the alternatives along with the pros and cons. eira:adr_decision: The decision describes the justification for why the particular solution was accepted. It has more emphasis on the why rather than the how. eira:adr_status: [Proposed (under review)|Accepted (approved and ready for implementation)|Superseded (superseded by another decision)] eira:adr_consecuences: The consequences section contains information about the overall impact of an architectural decision. Every decision has trade-offs. That’s why it’s crucial to include the analysis to provide a clear picture. Definition: Architecture Decision Record from where you should specialise the ADR SBBs regarding the Scalability for Growth Source: ISO/IEC/IEEE 42010:2022 Source reference: https://www.iso.org/standard/74393.html Additional information: Scalability for Growth is a decision that refers to the ability of a system or application to handle an increasing amount of workload or traffic without compromising its performance or stability. This concept is essential for businesses that are looking to expand their operations and need to ensure that their IT infrastructure can support their growth. Scalability can be achieved through various techniques such as horizontal scaling, vertical scaling, load balancing, and caching. By designing an IT architecture that is scalable, businesses can ensure that their systems can handle increased demand and provide a seamless user experience. Example: Scalability for Growth: Decision: Designing the software system with scalability in mind to support future business growth. Rationale: Scalability ensures that the system can handle increasing user demands, accommodate higher data volumes, and support business expansion without significant re-architecture or performance issues. LOST view: Digital Solution Architecture Decisions Catalogue view Identifier: http://data.europa.eu/dr8/egovera/ScalabilityForGrowthGoal EIRA traceability: eira:DigitalSolutionArchitectureDecisionGoal ABB name: egovera:ScalabilityForGrowthGoal EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-06-15 dct:identifier: ADR-20230515180947555 dct:title: Architecture Decision Record about Scalability for Growth eira:adr_context: The context explains why we need to make a decision. It also describes the alternatives along with the pros and cons. eira:adr_decision: The decision describes the justification for why the particular solution was accepted. It has more emphasis on the why rather than the how. eira:adr_status: [Proposed (under review)|Accepted (approved and ready for implementation)|Superseded (superseded by another decision)] eira:adr_consecuences: The consequences section contains information about the overall impact of an architectural decision. Every decision has trade-offs. That’s why it’s crucial to include the analysis to provide a clear picture. Definition: Architecture Decision Record from where you should specialise the ADR SBBs regarding the Internazionalization and Localization Source: ISO/IEC/IEEE 42010:2022 Source reference: https://www.iso.org/standard/74393.html Additional information: The decision of internationalization and localization in IT architecture refers to the process of designing software applications that can be adapted to different languages, cultures, and regions. Internationalization involves creating software that can handle different character sets, date and time formats, and other cultural differences. Localization involves adapting the software to a specific language and culture, including translating text, adjusting graphics, and modifying functionality to meet local requirements. This concept is important for companies that operate in multiple countries and need to provide software that can be used by people with different backgrounds and languages. Example: Internationalization and Localization: Decision: Building support for multiple languages and cultural adaptations into the software system. Rationale: Internationalization and localization enable the organization to reach a broader global market, cater to diverse customer preferences, and provide a localized user experience, leading to increased customer satisfaction and market penetration. LOST view: Digital Solution Architecture Decisions Catalogue view Identifier: http://data.europa.eu/dr8/egovera/InternazionalizationAndLocalizationGoal EIRA traceability: eira:DigitalSolutionArchitectureDecisionGoal ABB name: egovera:InternazionalizationAndLocalizationGoal EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-06-15 dct:identifier: ADR-20230515180947623 dct:title: Architecture Decision Record about Internazionalization and Localization eira:adr_context: The context explains why we need to make a decision. It also describes the alternatives along with the pros and cons. eira:adr_decision: The decision describes the justification for why the particular solution was accepted. It has more emphasis on the why rather than the how. eira:adr_status: [Proposed (under review)|Accepted (approved and ready for implementation)|Superseded (superseded by another decision)] eira:adr_consecuences: The consequences section contains information about the overall impact of an architectural decision. Every decision has trade-offs. That’s why it’s crucial to include the analysis to provide a clear picture. Definition: Architecture Decision Record from where you should specialise the ADR SBBs regarding the Dynamic Location of Data provider Source: ISO/IEC/IEEE 42010:2022 Source reference: https://www.iso.org/standard/74393.html Additional information: The concept of Dynamic Location of Data Provider in IT architecture refers to the ability of a system to automatically determine the best location for data storage and retrieval based on various factors such as network latency, availability of resources, and user location. This approach allows for more efficient use of resources and faster access to data, as the system can dynamically adjust to changing conditions and optimize performance. Additionally, it can help to reduce costs by minimizing the need for manual intervention and maintenance. Overall, the dynamic location of data provider concept is an important consideration in modern IT architecture design, particularly for systems that require high levels of performance and scalability. Example: Decision: The Data Provider capable of providing the required evidence is dynamically located. Consequence: New Capability: Data Provider Capability Management, including Data Provider Discovery LOST view: Digital Solution Architecture Decisions Catalogue view Identifier: http://data.europa.eu/dr8/egovera/DynamicLocationOfDataProviderGoal EIRA traceability: eira:DigitalSolutionArchitectureDecisionGoal ABB name: egovera:DynamicLocationOfDataProviderGoal EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-06-15 dct:identifier: ADR-20230515180947784 dct:title: Architecture Decision Record about Dynamic Location of Data provider eira:adr_context: The context explains why we need to make a decision. It also describes the alternatives along with the pros and cons. eira:adr_decision: The decision describes the justification for why the particular solution was accepted. It has more emphasis on the why rather than the how. eira:adr_status: [Proposed (under review)|Accepted (approved and ready for implementation)|Superseded (superseded by another decision)] eira:adr_consecuences: The consequences section contains information about the overall impact of an architectural decision. Every decision has trade-offs. That’s why it’s crucial to include the analysis to provide a clear picture. Definition: Architecture Decision Record from where you should specialise the ADR SBBs regarding the Learning Source: ISO/IEC/IEEE 42010:2022 Source reference: https://www.iso.org/standard/74393.html Additional information: User learning, in the context of usability, refers to the process by which users acquire the knowledge and skills necessary to effectively and efficiently interact with a software system. It involves understanding the system's functionality, features, and workflows, as well as learning how to navigate interfaces and perform tasks. Example: Title: User Learning Architecture Decision Record (ADR) LOST view: Digital Solution Architecture Decisions Catalogue view Identifier: http://data.europa.eu/dr8/egovera/LearningGoal EIRA traceability: eira:DigitalSolutionArchitectureDecisionGoal ABB name: egovera:LearningGoal EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-07-06 dct:identifier: ADR-20230606091024693 dct:title: Architecture Decision Record about Learning eira:adr_context: The context explains why we need to make a decision. It also describes the alternatives along with the pros and cons. eira:adr_decision: The decision describes the justification for why the particular solution was accepted. It has more emphasis on the why rather than the how. eira:adr_status: [Proposed (under review)|Accepted (approved and ready for implementation)|Superseded (superseded by another decision)] eira:adr_consecuences: The consequences section contains information about the overall impact of an architectural decision. Every decision has trade-offs. That’s why it’s crucial to include the analysis to provide a clear picture. Definition: Architecture Decision Record from where you should specialise the ADR SBBs regarding the UserInterface Source: ISO/IEC/IEEE 42010:2022 Source reference: https://www.iso.org/standard/74393.html Additional information: Accessibility in the context of usability refers to the design and implementation of a software system that ensures equal access and usability for all users, including those with disabilities or impairments. It focuses on creating an inclusive user experience by removing barriers and providing accommodations to enable individuals with disabilities to perceive, understand, navigate, and interact with the system effectively. Example: Title: Accessibility Architecture Decision Record (ADR) LOST view: Digital Solution Architecture Decisions Catalogue view Identifier: http://data.europa.eu/dr8/egovera/AccessibilityGoal EIRA traceability: eira:DigitalSolutionArchitectureDecisionGoal ABB name: egovera:AccessibilityGoal EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-07-06 dct:identifier: ADR-20230606091024752 dct:title: Architecture Decision Record about UserInterface eira:adr_context: The context explains why we need to make a decision. It also describes the alternatives along with the pros and cons. eira:adr_decision: The decision describes the justification for why the particular solution was accepted. It has more emphasis on the why rather than the how. eira:adr_status: [Proposed (under review)|Accepted (approved and ready for implementation)|Superseded (superseded by another decision)] eira:adr_consecuences: The consequences section contains information about the overall impact of an architectural decision. Every decision has trade-offs. That’s why it’s crucial to include the analysis to provide a clear picture. Definition: Architecture Decision Record from where you should specialise the ADR SBBs regarding the Content Delivery Network Source: ISO/IEC/IEEE 42010:2022 Source reference: https://www.iso.org/standard/74393.html Additional information: A Content Delivery Network (CDN) is a distributed network of servers that work together to deliver content to end-users. The concept of a CDN is to reduce the latency and improve the performance of websites and applications by caching content closer to the end-users. This is achieved by replicating the content across multiple servers in different geographic locations, allowing users to access the content from the server closest to them. CDNs are commonly used for delivering static content such as images, videos, and other media files. They can also be used for dynamic content such as web applications and APIs. CDNs can improve website performance, reduce server load, and provide better user experience. Example: Content Delivery Network (CDN): Decision: Utilizing a CDN to distribute static content and media files closer to end-users. Rationale: A CDN improves performance by caching and delivering content from edge servers located in various geographic regions, reducing latency and improving the overall user experience. LOST view: Digital Solution Architecture Decisions Catalogue view Identifier: http://data.europa.eu/dr8/egovera/ContentDeliveryNetworkGoal EIRA traceability: eira:DigitalSolutionArchitectureDecisionGoal ABB name: egovera:ContentDeliveryNetworkGoal EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-06-15 dct:identifier: ADR-20230515180947430 dct:title: Architecture Decision Record about Content Delivery Network eira:adr_context: The context explains why we need to make a decision. It also describes the alternatives along with the pros and cons. eira:adr_decision: The decision describes the justification for why the particular solution was accepted. It has more emphasis on the why rather than the how. eira:adr_status: [Proposed (under review)|Accepted (approved and ready for implementation)|Superseded (superseded by another decision)] eira:adr_consecuences: The consequences section contains information about the overall impact of an architectural decision. Every decision has trade-offs. That’s why it’s crucial to include the analysis to provide a clear picture. Definition: Architecture Decision Record from where you should specialise the ADR SBBs regarding the Version Control Source: ISO/IEC/IEEE 42010:2022 Source reference: https://www.iso.org/standard/74393.html Additional information: This ADR focuses on decisions related to version control systems and practices. It includes decisions on the selection and configuration of version control tools (e.g., Git, SVN), branching strategies, and guidelines for effective collaboration among developers. Example: Title: Version Control Architecture Decision Record (ADR) LOST view: Digital Solution Architecture Decisions Catalogue view Identifier: http://data.europa.eu/dr8/egovera/VersionControlGoal EIRA traceability: eira:DigitalSolutionArchitectureDecisionGoal ABB name: egovera:VersionControlGoal EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-07-06 dct:identifier: ADR-20230606091024749 dct:title: Architecture Decision Record about Version Control eira:adr_context: The context explains why we need to make a decision. It also describes the alternatives along with the pros and cons. eira:adr_decision: The decision describes the justification for why the particular solution was accepted. It has more emphasis on the why rather than the how. eira:adr_status: [Proposed (under review)|Accepted (approved and ready for implementation)|Superseded (superseded by another decision)] eira:adr_consecuences: The consequences section contains information about the overall impact of an architectural decision. Every decision has trade-offs. That’s why it’s crucial to include the analysis to provide a clear picture. Definition: Architecture Decision Record from where you should specialise the ADR SBBs regarding the Network Optimization Source: ISO/IEC/IEEE 42010:2022 Source reference: https://www.iso.org/standard/74393.html Additional information: Network optimization is a concept in IT architecture that involves improving the performance and efficiency of a computer network. This can be achieved through various techniques such as reducing network congestion, optimizing routing protocols, improving bandwidth utilization, and implementing load balancing. The goal of network optimization is to ensure that the network can handle the increasing demands of data traffic and provide a seamless user experience. It is an important consideration for organizations that rely heavily on their network infrastructure to support their business operations. Example: Network Optimization: Decision: Implementing network optimization techniques, such as compression, caching, and minimizing network round trips, to reduce latency and improve data transmission efficiency. Rationale: Optimizing network communication improves system performance by reducing the time required to transfer data and improving the utilization of network resources. LOST view: Digital Solution Architecture Decisions Catalogue view Identifier: http://data.europa.eu/dr8/egovera/NetworkOptimizationGoal EIRA traceability: eira:DigitalSolutionArchitectureDecisionGoal ABB name: egovera:NetworkOptimizationGoal EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-06-15 dct:identifier: ADR-20230515180947421 dct:title: Architecture Decision Record about Network Optimization eira:adr_context: The context explains why we need to make a decision. It also describes the alternatives along with the pros and cons. eira:adr_decision: The decision describes the justification for why the particular solution was accepted. It has more emphasis on the why rather than the how. eira:adr_status: [Proposed (under review)|Accepted (approved and ready for implementation)|Superseded (superseded by another decision)] eira:adr_consecuences: The consequences section contains information about the overall impact of an architectural decision. Every decision has trade-offs. That’s why it’s crucial to include the analysis to provide a clear picture. Definition: Architecture Decision Record from where you should specialise the ADR SBBs regarding the Database Sharding Source: ISO/IEC/IEEE 42010:2022 Source reference: https://www.iso.org/standard/74393.html Additional information: Database sharding ADR is a decision to choose the technique used in distributed databases to improve scalability and performance. It involves partitioning a large database into smaller, more manageable pieces called shards, which are distributed across multiple servers. Each shard contains a subset of the data, and queries are routed to the appropriate shard based on a predefined sharding key. This allows for faster query processing and reduces the risk of data loss or downtime in the event of a server failure. However, implementing database sharding requires careful planning and coordination to ensure data consistency and availability. Example: Database Sharding: Decision: Implementing database sharding to distribute data across multiple database instances. Rationale: Sharding allows for horizontal scaling of the database by splitting data into smaller partitions and distributing them across multiple database servers, improving performance and accommodating increased data volume. LOST view: Digital Solution Architecture Decisions Catalogue view Identifier: http://data.europa.eu/dr8/egovera/DatabaseShardingGoal EIRA traceability: eira:DigitalSolutionArchitectureDecisionGoal ABB name: egovera:DatabaseShardingGoal EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-06-15 dct:identifier: ADR-20230515180947693 dct:title: Architecture Decision Record about Database Sharding eira:adr_context: The context explains why we need to make a decision. It also describes the alternatives along with the pros and cons. eira:adr_decision: The decision describes the justification for why the particular solution was accepted. It has more emphasis on the why rather than the how. eira:adr_status: [Proposed (under review)|Accepted (approved and ready for implementation)|Superseded (superseded by another decision)] eira:adr_consecuences: The consequences section contains information about the overall impact of an architectural decision. Every decision has trade-offs. That’s why it’s crucial to include the analysis to provide a clear picture. Definition: Architecture Decision Record from where you should specialise the ADR SBBs regarding the Use GNU GPL as License Source: ISO/IEC/IEEE 42010:2022 Source reference: https://www.iso.org/standard/74393.html Additional information: The decision to use GNU GPL as a license concept is a strategic choice made by companies and organizations that want to promote the use and distribution of open-source software. The GNU GPL license allows users to modify and distribute the software freely if they also make their modifications available under the same license. This creates a collaborative environment where developers can work together to improve the software and build upon each other's work. Additionally, the GNU GPL license ensures that the software remains open-source and free for all to use, preventing any one entity from monopolizing the technology. Example: Internationalization and Localization: Decision: Chosen option: "GNU GPL", because this license supports a strong copyleft model. Rationale: Everything needs to be licensed, otherwise the default copyright laws apply. For instance, in Germany that means users may not alter anything without explicitly asking for permission. For more information see https://help.github.com/articles/licensing-a-repository/. We want to have all source code related to Operate First to be used without any hassle and as free as possible, so that users can just execute and enjoy the four freedoms. LOST view: Digital Solution Architecture Decisions Catalogue view Identifier: http://data.europa.eu/dr8/egovera/UseGNUGPLAsLicenseGoal EIRA traceability: eira:DigitalSolutionArchitectureDecisionGoal ABB name: egovera:UseGNUGPLAsLicenseGoal EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-06-15 dct:identifier: ADR-20230515180947412 dct:title: Architecture Decision Record about Use GNU GPL as License eira:adr_context: The context explains why we need to make a decision. It also describes the alternatives along with the pros and cons. eira:adr_decision: The decision describes the justification for why the particular solution was accepted. It has more emphasis on the why rather than the how. eira:adr_status: [Proposed (under review)|Accepted (approved and ready for implementation)|Superseded (superseded by another decision)] eira:adr_consecuences: The consequences section contains information about the overall impact of an architectural decision. Every decision has trade-offs. That’s why it’s crucial to include the analysis to provide a clear picture. Definition: Architecture Decision Record from where you should specialise the ADR SBBs regarding the Encryption Standards Source: ISO/IEC/IEEE 42010:2022 Source reference: https://www.iso.org/standard/74393.html Additional information: Encryption standards refer to the set of protocols and algorithms used to secure data and information. These standards ensure that sensitive information is protected from unauthorized access, theft, or manipulation. The choice of encryption standards is critical in IT architecture decisions as it determines the level of security and protection that the system can provide. The most used encryption standards include AES, RSA, and SHA, among others. The selection of encryption standards depends on the specific needs of the organization, the type of data being protected, and the level of security required. The implementation of encryption standards requires careful planning and management to ensure that the system is secure and effective. Example: Encryption Standards: Decision: Using Advanced Encryption Standard (AES) with a key length of 256 bits for data encryption at rest. Rationale: AES-256 is a widely accepted and secure encryption algorithm, providing strong protection for sensitive data stored on disk or in databases. LOST view: Digital Solution Architecture Decisions Catalogue view Identifier: http://data.europa.eu/dr8/egovera/EncryptionStandardsGoal EIRA traceability: eira:DigitalSolutionArchitectureDecisionGoal ABB name: egovera:EncryptionStandardsGoal EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-06-15 dct:identifier: ADR-20230515180947536 dct:title: Architecture Decision Record about Encryption Standards eira:adr_context: The context explains why we need to make a decision. It also describes the alternatives along with the pros and cons. eira:adr_decision: The decision describes the justification for why the particular solution was accepted. It has more emphasis on the why rather than the how. eira:adr_status: [Proposed (under review)|Accepted (approved and ready for implementation)|Superseded (superseded by another decision)] eira:adr_consecuences: The consequences section contains information about the overall impact of an architectural decision. Every decision has trade-offs. That’s why it’s crucial to include the analysis to provide a clear picture. Definition: Architecture Decision Record from where you should specialise the ADR SBBs regarding the Secure Communications Source: ISO/IEC/IEEE 42010:2022 Source reference: https://www.iso.org/standard/74393.html Additional information: The Secure Communications concept in IT architecture decision-making refers to the implementation of measures that ensure the confidentiality, integrity, and availability of data transmitted between different systems or devices. This includes the use of encryption, digital signatures, and secure protocols such as SSL/TLS to protect data in transit from unauthorized access, interception, or modification. The Secure Communications concept is critical in ensuring the security of sensitive information such as financial transactions, personal data, and intellectual property. It is also essential for compliance with regulatory requirements such as HIPAA, PCI DSS, and GDPR. Example: Secure Communications: Decision: Enforcing Transport Layer Security (TLS) for secure communication over the network. Rationale: TLS ensures that data transmitted between client and server is encrypted, preventing eavesdropping, tampering, and unauthorized interception of sensitive information. LOST view: Digital Solution Architecture Decisions Catalogue view Identifier: http://data.europa.eu/dr8/egovera/SecureCommunicationsGoal EIRA traceability: eira:DigitalSolutionArchitectureDecisionGoal ABB name: egovera:SecureCommunicationsGoal EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-06-15 dct:identifier: ADR-20230515180947469 dct:title: Architecture Decision Record about Secure Communications eira:adr_context: The context explains why we need to make a decision. It also describes the alternatives along with the pros and cons. eira:adr_decision: The decision describes the justification for why the particular solution was accepted. It has more emphasis on the why rather than the how. eira:adr_status: [Proposed (under review)|Accepted (approved and ready for implementation)|Superseded (superseded by another decision)] eira:adr_consecuences: The consequences section contains information about the overall impact of an architectural decision. Every decision has trade-offs. That’s why it’s crucial to include the analysis to provide a clear picture. Definition: Architecture Decision Record from where you should specialise the ADR SBBs regarding the Cross-border User Authentication Operations Source: ISO/IEC/IEEE 42010:2022 Source reference: https://www.iso.org/standard/74393.html Additional information: Cross-border User Authentication Operations concept refers to the process of verifying the identity of users who are accessing digital services across different countries. It involves the use of various authentication methods such as biometrics, passwords, and tokens to ensure that only authorized users can access the services. It helps to enhance security, reduce fraud, and ensure compliance with regulatory requirements. The implementation of cross-border user authentication operations requires careful consideration of various factors such as legal and regulatory requirements, technical capabilities, and user experience. Example: Decision: The Identity Provider operates the cross-border authentication of the User. Consequence: Identity Provider is a new role in business ops LOST view: Digital Solution Architecture Decisions Catalogue view Identifier: http://data.europa.eu/dr8/egovera/Cross-borderUserAuthenticationOperationsGoal EIRA traceability: eira:DigitalSolutionArchitectureDecisionGoal ABB name: egovera:Cross-borderUserAuthenticationOperationsGoal EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-06-15 dct:identifier: ADR-20230515180947814 dct:title: Architecture Decision Record about Cross-border User Authentication Operations eira:adr_context: The context explains why we need to make a decision. It also describes the alternatives along with the pros and cons. eira:adr_decision: The decision describes the justification for why the particular solution was accepted. It has more emphasis on the why rather than the how. eira:adr_status: [Proposed (under review)|Accepted (approved and ready for implementation)|Superseded (superseded by another decision)] eira:adr_consecuences: The consequences section contains information about the overall impact of an architectural decision. Every decision has trade-offs. That’s why it’s crucial to include the analysis to provide a clear picture. Definition: Architecture Decision Record from where you should specialise the ADR SBBs regarding the Data Subscription Capability Source: ISO/IEC/IEEE 42010:2022 Source reference: https://www.iso.org/standard/74393.html Additional information: The Data Subscription Capability ADR is a decision made in IT architecture that allows users to subscribe to specific data sets or streams. This capability enables users to receive real-time updates and notifications when new data is available, without having to constantly check for updates manually. This concept is particularly useful for businesses that rely on real-time data for decision-making, such as financial institutions or stock traders. By subscribing to specific data sets, users can stay informed and make informed decisions quickly and efficiently. Additionally, the Data Subscription Capability ADR can help reduce data overload by allowing users to filter out irrelevant data and focus on the information that is most important to them. Example: Decision: The Data Consumer controls the notification through a subscription to Data changes Consequence: New capability: Data Consumer Data Subscription LOST view: Digital Solution Architecture Decisions Catalogue view Identifier: http://data.europa.eu/dr8/egovera/DataSubscriptionCapabilityGoal EIRA traceability: eira:DigitalSolutionArchitectureDecisionGoal ABB name: egovera:DataSubscriptionCapabilityGoal EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-06-15 dct:identifier: ADR-20230515180947846 dct:title: Architecture Decision Record about Data Subscription Capability eira:adr_context: The context explains why we need to make a decision. It also describes the alternatives along with the pros and cons. eira:adr_decision: The decision describes the justification for why the particular solution was accepted. It has more emphasis on the why rather than the how. eira:adr_status: [Proposed (under review)|Accepted (approved and ready for implementation)|Superseded (superseded by another decision)] eira:adr_consecuences: The consequences section contains information about the overall impact of an architectural decision. Every decision has trade-offs. That’s why it’s crucial to include the analysis to provide a clear picture. Definition: Architecture Decision Record from where you should specialise the ADR SBBs regarding the Load Balancing Strategy Source: ISO/IEC/IEEE 42010:2022 Source reference: https://www.iso.org/standard/74393.html Additional information: Load balancing strategy is a decision in IT architecture that involves distributing network traffic across multiple servers to ensure optimal performance, availability, and scalability. The strategy involves selecting the appropriate load balancing algorithm, such as round-robin, least connections, or IP hash, based on the specific needs of the application and infrastructure. The load balancer acts as a traffic cop, directing incoming requests to the most available and responsive server, reducing downtime, and improving user experience. The load balancing strategy also involves monitoring and analyzing traffic patterns, adjusting server capacity, and implementing failover mechanisms to ensure high availability and fault tolerance. Example: Load Balancing Strategy: Decision: Implementing a load balancing mechanism, such as round-robin or dynamic load balancing, to distribute incoming traffic across multiple servers. Rationale: Load balancing ensures that incoming requests are evenly distributed among servers, preventing any single server from becoming overwhelmed and maintaining consistent performance under high loads. LOST view: Digital Solution Architecture Decisions Catalogue view Identifier: http://data.europa.eu/dr8/egovera/LoadBalancingStrategyGoal EIRA traceability: eira:DigitalSolutionArchitectureDecisionGoal ABB name: egovera:LoadBalancingStrategyGoal EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-06-15 dct:identifier: ADR-20230515180947508 dct:title: Architecture Decision Record about Load Balancing Strategy eira:adr_context: The context explains why we need to make a decision. It also describes the alternatives along with the pros and cons. eira:adr_decision: The decision describes the justification for why the particular solution was accepted. It has more emphasis on the why rather than the how. eira:adr_status: [Proposed (under review)|Accepted (approved and ready for implementation)|Superseded (superseded by another decision)] eira:adr_consecuences: The consequences section contains information about the overall impact of an architectural decision. Every decision has trade-offs. That’s why it’s crucial to include the analysis to provide a clear picture. Definition: Architecture Decision Record from where you should specialise the ADR SBBs regarding the Adaptability Source: ISO/IEC/IEEE 42010:2022 Source reference: https://www.iso.org/standard/74393.html Additional information: Adaptability in software architecture refers to the design and characteristics of a software system that allow it to easily and efficiently respond to changing requirements, technologies, and environmental conditions. An adaptable software architecture enables the system to evolve and adapt over time, facilitating seamless updates and modifications without significant disruption. Example: Title: Adaptability Architecture Decision Record (ADR) LOST view: Digital Solution Architecture Decisions Catalogue view Identifier: http://data.europa.eu/dr8/egovera/AdaptabilityGoal EIRA traceability: eira:DigitalSolutionArchitectureDecisionGoal ABB name: egovera:AdaptabilityGoal EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-07-06 dct:identifier: ADR-20230606091024687 dct:title: Architecture Decision Record about Adaptability eira:adr_context: The context explains why we need to make a decision. It also describes the alternatives along with the pros and cons. eira:adr_decision: The decision describes the justification for why the particular solution was accepted. It has more emphasis on the why rather than the how. eira:adr_status: [Proposed (under review)|Accepted (approved and ready for implementation)|Superseded (superseded by another decision)] eira:adr_consecuences: The consequences section contains information about the overall impact of an architectural decision. Every decision has trade-offs. That’s why it’s crucial to include the analysis to provide a clear picture. Definition: Architecture Decision Record from where you should specialise the ADR SBBs regarding the Technology Stack Selection Source: ISO/IEC/IEEE 42010:2022 Source reference: https://www.iso.org/standard/74393.html Additional information: Technology Stack Selection SBB is a crucial decision in IT architecture that involves choosing the appropriate set of technologies, frameworks, and tools to build a software application. The technological stack selection process involves evaluating various factors such as scalability, performance, security, ease of maintenance, and cost-effectiveness. The technology stack includes the programming language, database, web server, operating system, and other software components required to build the application. The right technology stack selection can significantly impact the success of the software application (or architecture), as it can affect the development time, cost, and overall quality of the product. Example: Technology Stack Selection: Decision: Selecting Node.js and React.js as the primary technologies for a web application. Rationale: Node.js provides a lightweight and scalable runtime environment for the backend, while React.js offers a component-based approach for building responsive and interactive user interfaces. LOST view: Digital Solution Architecture Decisions Catalogue view Identifier: http://data.europa.eu/dr8/egovera/TechnologyStackSelectionGoal EIRA traceability: eira:DigitalSolutionArchitectureDecisionGoal ABB name: egovera:TechnologyStackSelectionGoal EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-06-15 dct:identifier: ADR-20230515180947724 dct:title: Architecture Decision Record about Technology Stack Selection eira:adr_context: The context explains why we need to make a decision. It also describes the alternatives along with the pros and cons. eira:adr_decision: The decision describes the justification for why the particular solution was accepted. It has more emphasis on the why rather than the how. eira:adr_status: [Proposed (under review)|Accepted (approved and ready for implementation)|Superseded (superseded by another decision)] eira:adr_consecuences: The consequences section contains information about the overall impact of an architectural decision. Every decision has trade-offs. That’s why it’s crucial to include the analysis to provide a clear picture. Definition: Architecture Decision Record from where you should specialise the ADR SBBs regarding the Big-Data Architecture Source: ISO/IEC/IEEE 42010:2022 Source reference: https://www.iso.org/standard/74393.html Additional information: Big Data Architecture is a framework or blueprint that outlines the design, components, and processes required to handle and analyze large volumes of data. It encompasses the infrastructure, tools, and methodologies used to capture, store, process, and analyze diverse and complex data sets in a scalable and efficient manner. Example: Title: Big Data Architecture Decision Record (ADR) LOST view: Digital Solution Architecture Decisions Catalogue view Identifier: http://data.europa.eu/dr8/egovera/Big-DataArchitectureGoal EIRA traceability: eira:DigitalSolutionArchitectureDecisionGoal ABB name: egovera:Big-DataArchitectureGoal EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-08-20 dct:identifier: http://data.europa.eu/dr8/egovera/Big-DataArchitectureGoal dct:title: Architecture Decision Record about Big-Data Architecture eira:adr_context: The context explains why we need to make a decision. It also describes the alternatives along with the pros and cons. eira:adr_decision: The decision describes the justification for why the particular solution was accepted. It has more emphasis on the why rather than the how. eira:adr_status: [Proposed (under review)|Accepted (approved and ready for implementation)|Superseded (superseded by another decision)] eira:adr_consecuences: The consequences section contains information about the overall impact of an architectural decision. Every decision has trade-offs. That’s why it’s crucial to include the analysis to provide a clear picture. Definition: Architecture Decision Record from where you should specialise the ADR SBBs regarding the Database Schema Design Source: ISO/IEC/IEEE 42010:2022 Source reference: https://www.iso.org/standard/74393.html Additional information: Database Schema Design is an important decision in IT architecture that involves creating a logical representation of the database structure. It involves defining the tables, columns, relationships, and constraints that make up the database. The schema design should be optimized for the specific needs of the application and should be flexible enough to accommodate future changes. A well-designed schema can improve performance, reduce data redundancy, and ensure data integrity. It is important to consider factors such as scalability, security, and data access when making database schema design decisions. Example: Database Schema Design: Decision: Utilizing a denormalized schema design for a reporting database to optimize query performance. Rationale: Denormalizing the schema reduces the need for joins and improves query performance for reporting and analytics use cases, at the expense of increased data redundancy. LOST view: Digital Solution Architecture Decisions Catalogue view Identifier: http://data.europa.eu/dr8/egovera/DatabaseSchemaDesignGoal EIRA traceability: eira:DigitalSolutionArchitectureDecisionGoal ABB name: egovera:DatabaseSchemaDesignGoal EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-06-15 dct:identifier: ADR-20230515180947754 dct:title: Architecture Decision Record about Database Schema Design eira:adr_context: The context explains why we need to make a decision. It also describes the alternatives along with the pros and cons. eira:adr_decision: The decision describes the justification for why the particular solution was accepted. It has more emphasis on the why rather than the how. eira:adr_status: [Proposed (under review)|Accepted (approved and ready for implementation)|Superseded (superseded by another decision)] eira:adr_consecuences: The consequences section contains information about the overall impact of an architectural decision. Every decision has trade-offs. That’s why it’s crucial to include the analysis to provide a clear picture. Definition: Architecture Decision Record from where you should specialise the ADR SBBs regarding the Replaceability Source: ISO/IEC/IEEE 42010:2022 Source reference: https://www.iso.org/standard/74393.html Additional information: Replaceability in software architecture refers to the design and characteristics of a software system that enable individual components or modules to be easily replaced or substituted without significant impact on the overall functionality or integrity of the system. An architecture that supports replaceability allows for seamless replacement of components to accommodate evolving requirements, technology advancements, or business needs. Example: Title: Replaceability Architecture Decision Record (ADR) LOST view: Digital Solution Architecture Decisions Catalogue view Identifier: http://data.europa.eu/dr8/egovera/ReplaceabilityGoal EIRA traceability: eira:DigitalSolutionArchitectureDecisionGoal ABB name: egovera:ReplaceabilityGoal EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-07-06 dct:identifier: ADR-20230606091024772 dct:title: Architecture Decision Record about Replaceability eira:adr_context: The context explains why we need to make a decision. It also describes the alternatives along with the pros and cons. eira:adr_decision: The decision describes the justification for why the particular solution was accepted. It has more emphasis on the why rather than the how. eira:adr_status: [Proposed (under review)|Accepted (approved and ready for implementation)|Superseded (superseded by another decision)] eira:adr_consecuences: The consequences section contains information about the overall impact of an architectural decision. Every decision has trade-offs. That’s why it’s crucial to include the analysis to provide a clear picture. Definition: Architecture Decision Record from where you should specialise the ADR SBBs regarding the Event-Driven Architecture Source: ISO/IEC/IEEE 42010:2022 Source reference: https://www.iso.org/standard/74393.html Additional information: Event-Driven Architecture (EDA) is a software architecture pattern that emphasizes the production, detection, consumption, and reaction to events that occur within a system. It is a distributed computing model that allows for the creation of loosely coupled systems, where components can communicate with each other without the need for direct integration. EDA is particularly useful in systems that require real-time processing and decision-making, such as financial trading systems, sensor networks, and IoT applications. The key benefits of EDA include scalability, flexibility, and agility, as well as the ability to respond quickly to changing business requirements. Example: Event-Driven Architecture: Decision: Implementing an event-driven architecture using Apache Kafka for asynchronous communication between microservices. Rationale: Event-driven architectures enable loose coupling, scalability, and fault tolerance. Kafka provides a distributed messaging system with high throughput and fault-tolerant message persistence. LOST view: Digital Solution Architecture Decisions Catalogue view Identifier: http://data.europa.eu/dr8/egovera/Event-DrivenArchitectureGoal EIRA traceability: eira:DigitalSolutionArchitectureDecisionGoal ABB name: egovera:Event-DrivenArchitectureGoal EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-06-15 dct:identifier: ADR-20230515180947546 dct:title: Architecture Decision Record about Event-Driven Architecture eira:adr_context: The context explains why we need to make a decision. It also describes the alternatives along with the pros and cons. eira:adr_decision: The decision describes the justification for why the particular solution was accepted. It has more emphasis on the why rather than the how. eira:adr_status: [Proposed (under review)|Accepted (approved and ready for implementation)|Superseded (superseded by another decision)] eira:adr_consecuences: The consequences section contains information about the overall impact of an architectural decision. Every decision has trade-offs. That’s why it’s crucial to include the analysis to provide a clear picture. Definition: Architecture Decision Record from where you should specialise the ADR SBBs regarding the Elastic Cloud Infrastructure Source: ISO/IEC/IEEE 42010:2022 Source reference: https://www.iso.org/standard/74393.html Additional information: Elastic Cloud Infrastructure (ECI) is a concept in IT architecture that refers to a cloud-based infrastructure that can dynamically scale up or down based on the needs of the application or workload. This means that resources such as computing power, storage, and network bandwidth can be added or removed as required, allowing for greater flexibility and cost-effectiveness. ECI is often used in conjunction with containerization technologies such as Docker and Kubernetes, which allow applications to be packaged and deployed in a consistent and portable manner. ECI can also help to improve application performance and availability by distributing workloads across multiple servers or data centers. Example: Elastic Cloud Infrastructure: Decision: Utilizing cloud infrastructure services to dynamically adjust resources based on demand. Rationale: Cloud-based auto scaling enables the system to automatically add or remove compute resources in response to changes in workload, ensuring optimal resource allocation and scalability. LOST view: Digital Solution Architecture Decisions Catalogue view Identifier: http://data.europa.eu/dr8/egovera/ElasticCloudInfrastructureGoal EIRA traceability: eira:DigitalSolutionArchitectureDecisionGoal ABB name: egovera:ElasticCloudInfrastructureGoal EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-06-15 dct:identifier: ADR-20230515180947866 dct:title: Architecture Decision Record about Elastic Cloud Infrastructure eira:adr_context: The context explains why we need to make a decision. It also describes the alternatives along with the pros and cons. eira:adr_decision: The decision describes the justification for why the particular solution was accepted. It has more emphasis on the why rather than the how. eira:adr_status: [Proposed (under review)|Accepted (approved and ready for implementation)|Superseded (superseded by another decision)] eira:adr_consecuences: The consequences section contains information about the overall impact of an architectural decision. Every decision has trade-offs. That’s why it’s crucial to include the analysis to provide a clear picture. Definition: Architecture Decision Record from where you should specialise the ADR SBBs regarding the Security Incident Response Plan Source: ISO/IEC/IEEE 42010:2022 Source reference: https://www.iso.org/standard/74393.html Additional information: The Security Incident Response Plan is a concept that outlines the procedures and protocols that must be followed in the event of a security breach or incident. The plan typically includes steps for identifying the incident, containing the damage, investigating the cause, and restoring normal operations. It also includes guidelines for communication with stakeholders, such as customers, employees, and regulatory bodies. A well-designed Security Incident Response Plan can help minimize the impact of a security incident and reduce the risk of future incidents. Example: Security Incident Response Plan: Decision: Establishing a security incident response plan to handle and respond to security breaches or incidents promptly and effectively. Rationale: A well-defined incident response plan helps mitigate the impact of security incidents, comply with incident reporting requirements, and facilitate the recovery and restoration of systems and data. LOST view: Digital Solution Architecture Decisions Catalogue view Identifier: http://data.europa.eu/dr8/egovera/SecurityIncidentResponsePlanGoal EIRA traceability: eira:DigitalSolutionArchitectureDecisionGoal ABB name: egovera:SecurityIncidentResponsePlanGoal EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-06-15 dct:identifier: ADR-20230515180947794 dct:title: Architecture Decision Record about Security Incident Response Plan eira:adr_context: The context explains why we need to make a decision. It also describes the alternatives along with the pros and cons. eira:adr_decision: The decision describes the justification for why the particular solution was accepted. It has more emphasis on the why rather than the how. eira:adr_status: [Proposed (under review)|Accepted (approved and ready for implementation)|Superseded (superseded by another decision)] eira:adr_consecuences: The consequences section contains information about the overall impact of an architectural decision. Every decision has trade-offs. That’s why it’s crucial to include the analysis to provide a clear picture. Definition: Architecture Decision Record from where you should specialise the ADR SBBs regarding the Monetization Strategy Source: ISO/IEC/IEEE 42010:2022 Source reference: https://www.iso.org/standard/74393.html Additional information: Monetization strategy is a decision in IT architecture that determines how a company will generate revenue from its digital products or services. It involves identifying the target audience, understanding their needs and preferences, and developing a pricing model that aligns with the value proposition of the product or service. The monetization strategy can be based on various models such as subscription-based, pay-per-use, freemium, or advertising-based. The choice of the model depends on the nature of the product or service, the market demand, and the competitive landscape. A well-defined monetization strategy can help a company to maximize its revenue potential, build customer loyalty, and sustain long-term growth. Example: Decision: Implementing a subscription-based pricing model for a software-as-a-service (SaaS) product. Rationale: A subscription-based model provides recurring revenue and aligns with the target market's willingness to pay for ongoing access to the product's features and services. LOST view: Digital Solution Architecture Decisions Catalogue view Identifier: http://data.europa.eu/dr8/egovera/MonetizationStrategyGoal EIRA traceability: eira:DigitalSolutionArchitectureDecisionGoal ABB name: egovera:MonetizationStrategyGoal EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-06-15 dct:identifier: ADR-20230515180947575 dct:title: Architecture Decision Record about Monetization Strategy eira:adr_context: The context explains why we need to make a decision. It also describes the alternatives along with the pros and cons. eira:adr_decision: The decision describes the justification for why the particular solution was accepted. It has more emphasis on the why rather than the how. eira:adr_status: [Proposed (under review)|Accepted (approved and ready for implementation)|Superseded (superseded by another decision)] eira:adr_consecuences: The consequences section contains information about the overall impact of an architectural decision. Every decision has trade-offs. That’s why it’s crucial to include the analysis to provide a clear picture. Definition: Architecture Decision Record from where you should specialise the ADR SBBs regarding the Data Exchanger Operations Source: ISO/IEC/IEEE 42010:2022 Source reference: https://www.iso.org/standard/74393.html Additional information: The Data Exchanger Operations concept refers to the process of exchanging data between different systems or applications within an organization. This can involve transferring data from one database to another, integrating data from multiple sources, or sharing data between different departments or teams. The goal of Data Exchanger Operations is to ensure that data is accurate, up-to-date, and accessible to those who need it, while also maintaining data security and compliance with relevant regulations. This concept is an important part of IT architecture, as it helps to ensure that data is effectively managed and utilized throughout an organization. Example: Decision: The Data Exchanger role is operated by a separate entity than Data Consumer and Data Provider. Consequence: New entity potentially operating the Data Exchange responsibilities for both Data Consumers and Data Providers LOST view: Digital Solution Architecture Decisions Catalogue view Identifier: http://data.europa.eu/dr8/egovera/DataExchangerOperationsGoal EIRA traceability: eira:DigitalSolutionArchitectureDecisionGoal ABB name: egovera:DataExchangerOperationsGoal EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-06-15 dct:identifier: ADR-20230515180947517 dct:title: Architecture Decision Record about Data Exchanger Operations eira:adr_context: The context explains why we need to make a decision. It also describes the alternatives along with the pros and cons. eira:adr_decision: The decision describes the justification for why the particular solution was accepted. It has more emphasis on the why rather than the how. eira:adr_status: [Proposed (under review)|Accepted (approved and ready for implementation)|Superseded (superseded by another decision)] eira:adr_consecuences: The consequences section contains information about the overall impact of an architectural decision. Every decision has trade-offs. That’s why it’s crucial to include the analysis to provide a clear picture. Definition: Architecture Decision Record from where you should specialise the ADR SBBs regarding the Horizontal Scaling Source: ISO/IEC/IEEE 42010:2022 Source reference: https://www.iso.org/standard/74393.html Additional information: Horizontal scaling is a decision in IT architecture that involves adding more servers or nodes to a system to increase its capacity and performance. This approach is often used in distributed systems, where workloads can be spread across multiple servers to improve efficiency and reduce the risk of downtime. Horizontal scaling can be achieved through various techniques, such as load balancing, clustering, and sharding, and it can help organizations to scale their IT infrastructure in a cost-effective and flexible manner. However, horizontal scaling also requires careful planning and management to ensure that the system remains reliable and secure as it grows. Example: Horizontal Scaling: Decision: Adopting a microservices architecture to enable horizontal scaling of system components. Rationale: A microservices architecture allows for independent scaling of individual services based on demand, providing flexibility and the ability to allocate resources where they are most needed. LOST view: Digital Solution Architecture Decisions Catalogue view Identifier: http://data.europa.eu/dr8/egovera/HorizontalScalingGoal EIRA traceability: eira:DigitalSolutionArchitectureDecisionGoal ABB name: egovera:HorizontalScalingGoal EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-06-15 dct:identifier: ADR-20230515180947594 dct:title: Architecture Decision Record about Horizontal Scaling eira:adr_context: The context explains why we need to make a decision. It also describes the alternatives along with the pros and cons. eira:adr_decision: The decision describes the justification for why the particular solution was accepted. It has more emphasis on the why rather than the how. eira:adr_status: [Proposed (under review)|Accepted (approved and ready for implementation)|Superseded (superseded by another decision)] eira:adr_consecuences: The consequences section contains information about the overall impact of an architectural decision. Every decision has trade-offs. That’s why it’s crucial to include the analysis to provide a clear picture. Definition: Architecture Decision Record from where you should specialise the ADR SBBs regarding the Performance Testing and Tuning Source: ISO/IEC/IEEE 42010:2022 Source reference: https://www.iso.org/standard/74393.html Additional information: Performance testing and tuning is a decision of IT architecture that involves assessing the behavior of a system or application under different conditions and identifying areas where improvements can be made. This process helps to ensure that the system or application can handle the expected workload and provide a satisfactory user experience. Performance testing and tuning can involve a range of techniques, including load testing, stress testing, and capacity planning. It is an ongoing process that requires regular monitoring and adjustment to ensure optimal performance. Example: Performance Testing and Tuning: Decision: Conducting performance testing and tuning exercises regularly to identify bottlenecks and optimize system performance. Rationale: Performance testing helps uncover performance issues and provides insights into system limitations, enabling public administrations to make informed decisions on infrastructure scaling, code optimization, and configuration adjustments to enhance performance. LOST view: Digital Solution Architecture Decisions Catalogue view Identifier: http://data.europa.eu/dr8/egovera/PerformanceTestingAndTuningGoal EIRA traceability: eira:DigitalSolutionArchitectureDecisionGoal ABB name: egovera:PerformanceTestingAndTuningGoal EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-06-15 dct:identifier: ADR-20230515180947440 dct:title: Architecture Decision Record about Performance Testing and Tuning eira:adr_context: The context explains why we need to make a decision. It also describes the alternatives along with the pros and cons. eira:adr_decision: The decision describes the justification for why the particular solution was accepted. It has more emphasis on the why rather than the how. eira:adr_status: [Proposed (under review)|Accepted (approved and ready for implementation)|Superseded (superseded by another decision)] eira:adr_consecuences: The consequences section contains information about the overall impact of an architectural decision. Every decision has trade-offs. That’s why it’s crucial to include the analysis to provide a clear picture. Definition: Architecture Decision Record from where you should specialise the ADR SBBs regarding the Compliance with Data Privacy Regulations Source: ISO/IEC/IEEE 42010:2022 Source reference: https://www.iso.org/standard/74393.html Additional information: Compliance with data privacy regulations is a decision that ensures that an organization's data management practices align with the legal and regulatory requirements of the jurisdictions in which it operates. This decision involves implementing appropriate data protection measures, such as encryption, access controls, and data retention policies, to safeguard sensitive information from unauthorized access, use, or disclosure. Compliance with data privacy regulations also involves establishing clear policies and procedures for data handling, including data collection, storage, sharing, and disposal, to ensure that personal data is processed lawfully, fairly, and transparently. Failure to comply with data privacy regulations can result in severe legal and financial consequences, including fines, legal action, and reputational damage. Therefore, IT architecture decisions must prioritize compliance with data privacy regulations to protect the organization's data and reputation. Example: Compliance with Data Privacy Regulations: Decision: Ensuring compliance with the General Data Protection Regulation (GDPR) for handling customer data. Rationale: Compliance with GDPR builds trust with customers, reduces the risk of legal consequences, and enhances the organization's reputation in terms of data privacy and security. LOST view: Digital Solution Architecture Decisions Catalogue view Identifier: http://data.europa.eu/dr8/egovera/ComplianceWithDataPrivacyRegulationsGoal EIRA traceability: eira:DigitalSolutionArchitectureDecisionGoal ABB name: egovera:ComplianceWithDataPrivacyRegulationsGoal EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-06-15 dct:identifier: ADR-20230515180947734 dct:title: Architecture Decision Record about Compliance with Data Privacy Regulations eira:adr_context: The context explains why we need to make a decision. It also describes the alternatives along with the pros and cons. eira:adr_decision: The decision describes the justification for why the particular solution was accepted. It has more emphasis on the why rather than the how. eira:adr_status: [Proposed (under review)|Accepted (approved and ready for implementation)|Superseded (superseded by another decision)] eira:adr_consecuences: The consequences section contains information about the overall impact of an architectural decision. Every decision has trade-offs. That’s why it’s crucial to include the analysis to provide a clear picture. Definition: Architecture Decision Record from where you should specialise the ADR SBBs regarding the Retention and Data Deletion Source: ISO/IEC/IEEE 42010:2022 Source reference: https://www.iso.org/standard/74393.html Additional information: Retention and Data Deletion is a critical concept in IT architecture that deals with the management of data throughout its lifecycle. It involves the decision-making process of how long data should be kept, where it should be stored, and when it should be deleted. The concept is essential for organizations to comply with legal and regulatory requirements, protect sensitive information, and optimize storage resources. The retention and data deletion policy should be well-defined, communicated, and enforced to ensure data is managed effectively and efficiently. The policy should also consider the potential risks associated with data breaches, data loss, and unauthorized access. Example: Retention and Data Deletion: Decision: Implementing data retention policies and mechanisms for secure data deletion when no longer required. Rationale: Data retention and deletion policies ensure compliance with regulations governing the storage and retention of data, minimizing the risk of unauthorized access to obsolete or unnecessary data. LOST view: Digital Solution Architecture Decisions Catalogue view Identifier: http://data.europa.eu/dr8/egovera/RetentionAndDataDeletionGoal EIRA traceability: eira:DigitalSolutionArchitectureDecisionGoal ABB name: egovera:RetentionAndDataDeletionGoal EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-06-15 dct:identifier: ADR-20230515180947804 dct:title: Architecture Decision Record about Retention and Data Deletion eira:adr_context: The context explains why we need to make a decision. It also describes the alternatives along with the pros and cons. eira:adr_decision: The decision describes the justification for why the particular solution was accepted. It has more emphasis on the why rather than the how. eira:adr_status: [Proposed (under review)|Accepted (approved and ready for implementation)|Superseded (superseded by another decision)] eira:adr_consecuences: The consequences section contains information about the overall impact of an architectural decision. Every decision has trade-offs. That’s why it’s crucial to include the analysis to provide a clear picture. Definition: Interoperability Strategy ABB is a Goal that enables the ability of disparate and diverse organisations to interact towards mutually beneficial and agreed common goals, involving the sharing of information and knowledge between the organisations, through the business processes they support, by means of the exchange of data between their respective ICT systems. Source: EIF Source reference: http://eur-lex.europa.eu/resource.html?uri=cellar:2c2f2554-0faf-11e7-8a35-01aa75ed71a1.0017.02/DOC_3&format=PDF Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/InteroperabilityStrategyGoal LOST view: Organisational view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:InteroperabilityStrategyGoal Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): The vision laying down in the Interoperable Europe Act (see recitals) and additional information in https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A52022PC0720, and in https://www.europarl.europa.eu/legislative-train/theme-a-europe-fit-for-the-digital-age/file-eu-digital-interoperabilioty-strategy. Interoperability Saliency: The Interoperability Strategy ABB is salient for governance interoperability because it helps governments and public administrations to cooperate, share information and deliver public services seamlessly across borders, sectors and organizational boundaries. Thus, for example, the Interoperable Europe Act supports public sector innovation and public-private 'GovTech' projects. It sets up a new cooperation framework for interoperability in the public sector. Interoperability Dimension: Governance IoP Viewpoint: Interoperability Governance viewpoint Additional identifier: http://data.europa.eu/dr8/InteroperabilityStrategyGoal EIF Layer: Organisational DEFINITION: Achieve Organisational Interoperability ABB is Goal. For the purpose of the EIF, interoperability is the ability of organisations to interact towards mutually beneficial goals, involving the sharing of information and knowledge between these organisations, through the business processes they support, by means of the exchange of data between their ICT systems. The interoperability model which is applicable to all digital public services and may also be considered as an integral element of the interoperability-by-design paradigm. It includes: four layers of interoperability: legal, organisational, semantic and technical. Organisational interoperability refers to the way in which public administrations align their business processes, responsibilities and expectations to achieve commonly agreed and mutually beneficial goals. In practice, organisational interoperability means documenting and integrating or aligning business processes and relevant information exchanged. Organisational interoperability also aims to meet the requirements of the user community by making services available, easily identifiable, accessible and user-focused. Source: EIF (https://ec.europa.eu/isa2/sites/isa/files/eif_brochure_final.pdf) EXAMPLES: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Definition: Architecture Decision Record from where you should specialise the ADR SBBs regarding the Semantic Capability Source: ISO/IEC/IEEE 42010:2022 Source reference: https://www.iso.org/standard/74393.html Additional information: The Semantic Capability concept in IT architecture refers to the ability of a system or application to understand and interpret the meaning of data and information. This involves the use of semantic technologies such as ontologies, taxonomies, and metadata to provide context and structure to data, enabling better search, retrieval, and analysis. Semantic Capability is important in enabling interoperability between different systems and applications, as well as in supporting advanced analytics and decision-making processes. It is also a key enabler of the semantic interoperability, which aims to make data more accessible and useful by adding meaning and context to it. Example: Decision: The semantics heterogeneity of Evidence across Data Consumer’s and Data Provider’s is managed Consequence: New Capability: Evidence Semantic Management, including Semantic Mapping LOST view: Digital Solution Architecture Decisions Catalogue view Identifier: http://data.europa.eu/dr8/egovera/SemanticCapabilityGoal EIRA traceability: eira:DigitalSolutionArchitectureDecisionGoal ABB name: egovera:SemanticCapabilityGoal EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-06-15 dct:identifier: ADR-20230515180947488 dct:title: Architecture Decision Record about Semantic Capability eira:adr_context: The context explains why we need to make a decision. It also describes the alternatives along with the pros and cons. eira:adr_decision: The decision describes the justification for why the particular solution was accepted. It has more emphasis on the why rather than the how. eira:adr_status: [Proposed (under review)|Accepted (approved and ready for implementation)|Superseded (superseded by another decision)] eira:adr_consecuences: The consequences section contains information about the overall impact of an architectural decision. Every decision has trade-offs. That’s why it’s crucial to include the analysis to provide a clear picture. Definition: Architecture Decision Record from where you should specialise the ADR SBBs regarding the Caching Strategy Source: ISO/IEC/IEEE 42010:2022 Source reference: https://www.iso.org/standard/74393.html Additional information: Caching strategy is a concept in IT architecture that involves the use of caching mechanisms to improve the performance of applications and systems. Caching involves storing frequently accessed data in a cache, which is a temporary storage area that is closer to the application or system than the original data source. This reduces the time it takes to access the data, thereby improving the overall performance of the application or system. Example: Caching Mechanism: Decision: Implementing a distributed caching mechanism, such as Redis or Memcached, to improve response times and reduce database load. Rationale: Caching frequently accessed data in memory reduces the need for repeated database queries, resulting in faster response times, improved scalability, and reduced strain on the database infrastructure. LOST view: Digital Solution Architecture Decisions Catalogue view Identifier: http://data.europa.eu/dr8/egovera/CachingStrategyGoal EIRA traceability: eira:DigitalSolutionArchitectureDecisionGoal ABB name: egovera:CachingStrategyGoal EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-06-15 dct:identifier: ADR-20230515180947584 dct:title: Architecture Decision Record about Caching Strategy eira:adr_context: The context explains why we need to make a decision. It also describes the alternatives along with the pros and cons. eira:adr_decision: The decision describes the justification for why the particular solution was accepted. It has more emphasis on the why rather than the how. eira:adr_status: [Proposed (under review)|Accepted (approved and ready for implementation)|Superseded (superseded by another decision)] eira:adr_consecuences: The consequences section contains information about the overall impact of an architectural decision. Every decision has trade-offs. That’s why it’s crucial to include the analysis to provide a clear picture. Definition: Architecture Decision Record from where you should specialise the ADR SBBs regarding the Cross-Border Data Exchange Source: ISO/IEC/IEEE 42010:2022 Source reference: https://www.iso.org/standard/74393.html Additional information: Cross-border data exchange is a concept that refers to the transfer of data between different countries or regions. This can be done for various reasons, such as sharing information between businesses, governments, or individuals. The concept of cross-border data exchange is becoming increasingly important in today's globalized world, as more and more organizations are operating across borders and need to share information with partners and customers in different countries. However, there are also challenges associated with cross-border data exchange, such as data privacy and security concerns, legal and regulatory issues, and technical compatibility issues. Therefore, it is important for organizations to carefully consider the IT architecture decisions related to cross-border data exchange and ensure that they have appropriate policies, procedures, and technologies in place to manage these challenges effectively. Example: Decision: The Data Consumer and Data Provider rely on the Data Exchange Manager capability. Consequence: New capability: Evidence Data Management LOST view: Digital Solution Architecture Decisions Catalogue view Identifier: http://data.europa.eu/dr8/egovera/Cross-BorderDataExchangeGoal EIRA traceability: eira:DigitalSolutionArchitectureDecisionGoal ABB name: egovera:Cross-BorderDataExchangeGoal EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-06-15 dct:identifier: ADR-20230515180947774 dct:title: Architecture Decision Record about Cross-Border Data Exchange eira:adr_context: The context explains why we need to make a decision. It also describes the alternatives along with the pros and cons. eira:adr_decision: The decision describes the justification for why the particular solution was accepted. It has more emphasis on the why rather than the how. eira:adr_status: [Proposed (under review)|Accepted (approved and ready for implementation)|Superseded (superseded by another decision)] eira:adr_consecuences: The consequences section contains information about the overall impact of an architectural decision. Every decision has trade-offs. That’s why it’s crucial to include the analysis to provide a clear picture. Definition: Public Policy Objective ABB is a Goal allowing public authorities to set the path towards the implementation of a public strategy. Source: EuroVoc Source reference: http://eurovoc.europa.eu/drupal/?q=request&concepturi=http%3A%2F%2Feurovoc.europa.eu%2F8466&termuri=http%3A%2F%2Feurovoc.europa.eu%2F209598&language=en&view=pt&ifacelang=en Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/PublicPolicyObjectiveGoal LOST view: Legal view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:PublicPolicyObjectiveGoal Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): In 2021-2027 EU cohesion policy has set a shorter, modern menu of 5 policy objectives supporting growth for the period 2021-2027. The Joint Action Plan includes actions on: 1. a more competitive and smarter Europe; 2. a greener, low carbon transitioning towards a net zero carbon economy; 3. a more connected Europe by enhancing mobility; 4. a more social and inclusive Europe; 5. Europe closer to citizens by fostering the sustainable and integrated development of all types of territories (https://ec.europa.eu/regional_policy/2021-2027_en) Interoperability Saliency: The Public Policy Objective ABB is salient for the governance of interoperability because it sets the path toward the definition of courses of action and frameworks that facilitates data sharing across EU countries. This ABB also is salient for legal interoperability due to it will drive the specification of legal requirements for the enablement of interoperability. Additional information: Public Policy Objectives are usually formalized in the legislation. Thus, the EU data strategy is supported by a catalogue of legislation comprising the Data Act (https://digital-strategy.ec.europa.eu/en/policies/data-act), the Data Governance Act (https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:52020PC0767), the Interoperable Europe Act (https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A52022PC0720), and other ancillary binding legal instruments like the GDPR, eIDAS, the framework for the flow of non-personal data, as well as by non-binding instruments like the Communication of the Commission on a European data space (https://eur-lex.europa.eu/legal-content/en/ALL/?uri=CELEX%3A52018DC0232) Interoperability Dimension: Structural IoP Viewpoint: Enterprise Architecture Framework alignment guidelines viewpoint Additional identifier: http://data.europa.eu/dr8/PublicPolicyObjectiveGoal EIF Layer: Legal Definition: Interoperable Digital Solution ABB is a Goal that refers to a digital public service that can work seamlessly with other public services, systems and data across organisational and national boundaries Source: ISA2 Source reference: https://ec.europa.eu/isa2/eif_en/ eira:iopDimension: Structural IoP LOST view: Enterprise Architecture Framework alignment guidelines view Identifier: http://data.europa.eu/dr8/InteroperableEuropeanSolutionGoal ABB name: eira:InteroperableEuropeanSolutionGoal EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-04-24 dct:identifier: http://data.europa.eu/dr8/InteroperableEuropeanSolutionGoal Definition: Digital Public Services, the organisations behind them and the data managed need to incorporate the relevant mechanism to ensure overall trustworthiness. Trust entails citizens reliance on trustworthy and verifiable digital government applications and services, which fully conform to high-security standards and respond to user needs. Fundamental rights and security should be integrated into all policies with a digital dimension. To foster trust in digital interactions with the public sector, suitable regulatory frameworks that ensure transparency, predictability, security-by-design and, where necessary, reinforcement or adjustment of existing provisions must be provided. The principle has a horizontal approach, where it affects the adoption of legal measures, organisational mechanisms, and technical means to ensure services are part of a network of trustworthiness interactions. At the legal level, relevant and binding legislation needs to be put in place to ensure legal interoperability and guarantee that trust is the base of data interactions (exchange, processing, etc amongst digital public services).At the technical level, mechanisms, tools and standards should be part of processes certification that data exchange involving all stakeholders, is saved, with integrity and trustable. "" Source: Digital trust, from Shaping Europe’s digital future Source reference: https://digital-strategy.ec.europa.eu/en/policies/trust Last modification: 2024-01-17 Identifier: http://data.europa.eu/2sa/elap/trust EIRA concept: eira:ArchitectureBuildingBlock ABB name: elap:TrustPrinciple Title: Trust EIF Layer: N/A ABB Specialised: eira:EuropeanLibraryofArchitecturePrinciplesPrinciple Definition: Data and metadata availability through standardised mechanism and ensure its long-term availability Data retrieval should be mediated without specialised or proprietary tools or communication methods. This principle focuses on how data and metadata can be retrieved from their identifiersDatasets tend to degrade or disappear over time because there is a cost to maintaining an online presence for data resources. When this happens, links become invalid and users waste time hunting for data that might no longer be there. Then, metadata should persist even when the data are no longer sustained. Barriers to access that should be avoided include protocols that have limited implementation, poor documentation and components that require human manual intervention. For sensitive data, it is perfectly FAIR to provide an email, phone number or contact person who can discuss access to the data.Metadata must be treated at the same level as data, using the proper formats, and reusing relevant vocabularies that ensure its long-term availability. "" Source: FAIR Principles Source reference: https://www.go-fair.org/fair-principles/ Last modification: 2024-01-17 Identifier: http://data.europa.eu/2sa/elap/data-accessibility LOST view: TVA-Functional Architecture Principles EIRA concept: eira:ArchitectureBuildingBlock ABB name: elap:data-accessibility Title: Data Accessibility EIF Layer: N/A ABB Specialised: eira:EuropeanLibraryofArchitecturePrinciplesPrinciple Definition: Accessibility ensures that people with disabilities, the elderly and other disadvantaged groups can use public services at service levels comparable to those provided to other citizens. The trend towards a digital society provides users with new ways of accessing information and services. The providers of information and services, such as public sector bodies, rely increasingly on the internet to produce, collect and provide a wide range of information and services online which are essential to the public.Accessibility should be understood as principles and techniques to be observed when designing, constructing, maintaining, and updating websites and mobile applications in order to make them more accessible to users, in particular persons with disabilities. Member States shall ensure that public sector bodies take the necessary measures to make their websites and mobile applications more accessible by making them perceivable, operable, understandable and robust. Publisher: ELAP Source: Inclusion and accessibility is further incorporated in various industry standards, like WCAG (https://www.w3.org/WAI/standards-guidelines/wcag/) and OWASP (https://owasp.org) regarding secure offering of services over the web. Source reference: https://joinup.ec.europa.eu/collection/nifo-national-interoperability-framework-observatory/glossary/term/inclusion-and-accessibility Last modification: 2024-01-17 Identifier: http://data.europa.eu/2sa/elap/accessibility EIRA concept: eira:ArchitectureBuildingBlock ABB name: elap:AccessibilityPrinciple Title: Accessibility EIF Layer: N/A ABB Specialised: eira:EuropeanLibraryofArchitecturePrinciplesPrinciple Definition: Decide early on the type of deployment: On-premise, vs. Cloud-native and sourcing models IaaS, PaaS, SaaS, etc It is relevant for the success of Digital Public Services to select the deployment methodologies that fit the needs of the administration and stakeholders (citizens and businesses). Public administration needs to perform the proper benchmark analysis to select the proper methodology for the development of digital public services. This strategy needs to be present throughout the design process and the decision-making process to ensure the delivery of streamlined services according to the users needs. Source: EUROPEAN COMMISSION CLOUD STRATEGY Cloud as an enabler for the European Commission Digital Strategy Source reference: https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&ved=2ahUKEwj107ORv7v2AhX5gP0HHe4IBNwQFnoECBgQAQ&url=https%3A%2F%2Fec.europa.eu%2Finfo%2Fsites%2Fdefault%2Ffiles%2Fec_cloud_strategy.pdf&usg=AOvVaw09VDKvW8wCRo5ELg3gwH9C Last modification: 2024-01-17 Identifier: http://data.europa.eu/2sa/elap/deployment-fit-cloud-first-approach LOST view: Architecture Principles view EIRA concept: eira:ArchitectureBuildingBlock ABB name: elap:deployment-fit-cloud-first-approach Title: Deployment fit (Cloud-first approach) Additional information: It is relevant for the success of Digital Public Services to select the deployment methodologies that fit the needs of the administration and stakeholders (citizens and businesses). European Commission cloud strategy: "Cloud-first with a secure hybrid multi-cloud service offering". Cloud-first means that systems should rather be conceived in such a way that they can benefit from the advantages of cloud based delivery models, which exist both on premise and in the public cloud. The choice of architecture, especially of on premise and/or public cloud, will depend on the advantages, constraints and risks for a specific system. So it does not mean that all systems should go to the public cloud. EIF Layer: N/A ABB Specialised: eira:EuropeanLibraryofArchitecturePrinciplesPrinciple Definition: Every solution must support sustainability. The sourcing, operation and decommissioning of IT equipment should not indirectly or directly negatively affect economic, social and environmental aspects. Climate change is one of societys challenges for the upcoming decades, and public administrations shall be aware of and consider it when planning or implementing digital public services. Therefore, administrations and bodies in charge of developing public services according to public policies, need to consider the proper agreements that allow the reusing of existing services components and infrastructure to reduce the Carbon-dioxide e-footprint impact. Public Administrations need to reuse mainly physical or cloud existing infrastructures instead of creating ad-hoc technology and resources for delivering public services. Not only infrastructure but also technological equipment. Source: The European Parliament’s carbon footprint Towards carbon neutrality Source reference: https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&cad=rja&uact=8&ved=2ahUKEwjiofaGvLv2AhUThf0HHSXLBZoQFnoECAIQAQ&url=https%3A%2F%2Fwww.europarl.europa.eu%2FRegData%2Fetudes%2FSTUD%2F2020%2F652735%2FIPOL_STU(2020)652735_EN.pdf&usg=AOvVaw2CVqJPeLvN_ianAYdbLyi7 Last modification: 2024-01-17 Identifier: http://data.europa.eu/2sa/elap/carbon-dioxide-e-footprint-impact-awareness LOST view: OV-Governance Architecture Principles EIRA concept: eira:ArchitectureBuildingBlock ABB name: elap:carbon-dioxide-e-footprint-impact-awareness Title: Carbon-dioxide e-footprint impact awareness Additional information: Climate change is one of society's challenges for the upcoming decades, and public administrations shall be aware of and consider it when planning or implementing digital public services. Therefore, administrations and bodies in charge of developing public services according to public policies, need to consider the proper agreements that allow the reusing of existing services components and infrastructure to reduce the Carbon-dioxide e-footprint impact. Towards carbon neutrality - European Parliament: The study analyses the European Parliament’s (EP) carbon footprint in the context of the recent EP resolutions, in which it declared a climate emergency in Europe and requested the development of a strategy to become itself carbon-neutral by 2030. EIF Layer: N/A skos:broader: eira:EuropeanLibraryofArchitecturePrinciplesPrinciple Definition: EIF Principle ABB is a Principle analysing European Public Services by driving the identification and formulation of interoperability requirements with higher levels of granularity and used to design European public services by driving the identification and formulation of interoperability specifications Source: EIF Source reference: https://ec.europa.eu/isa2/eif_en Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Transparency: EIF Transparency Principle refers to: 1. Enabling visibility inside the administrative environment of a public administration. This is about allowing other public administrations, citizens and businesses to view and understand administrative rules, processes, data, services and decision-making. 2. Ensuring availability of interfaces with internal information systems. Public administrations operate a large number of what are often heterogeneous and disparate information systems in support of their internal processes. Interoperability depends on ensuring the availability of interfaces to these systems and the data they handle. In turn, interoperability facilitates reuse of systems and data, and enables these to be integrated into larger systems. 3. Securing the right to the protection of personal data, by respecting the applicable legal framework for the large volumes of personal data of citizens, held and managed by Public administrations.(https://ec.europa.eu/isa2/sites/default/files/eif_brochure_final.pdf) LOST view: Architecture Principle View Identifier: http://data.europa.eu/dr8/EifPrinciple eira:ID: ABB300 ABB name: eira:EifPrinciple Last modification: 2022-23-01 Definition: Organisations are loosely coupled with other organisations. Loosely coupled organisations are able to function with minimal dependency on other organisations. This enables faster implementation and change of digital public services. Any public organisation should avoid the entanglement of inter-organisational processes for performing activities, that spread over multiple organisations. The application for a visa, for instance, should be performed in a single transaction, from an applicants perspective. Whether the process comprises multiple interactions between public institutions (like Frontex, Embassy, Interpol) or not, should be transparent to the applicant. Inter-organisational interfaces in this case should not duplicate the processes, using the same data and leading to the same outcome. Each organisation serves a unique part of the application process. Loosely coupled integration can be achieved by establishing the proper organisational agreements, that ensure the proper implementation of digital public services without hampering any change or modification in those services. At technical and semantic layers, it can be achieved by reusing existing application services or core vocabularies that ensure interoperability between services without including dependencies between them. "" Source: Organizations Social Systems Conducting Experiments Source reference: https://link.springer.com/book/10.1007/978-3-642-14316-8 Last modification: 2024-01-17 Identifier: http://data.europa.eu/2sa/elap/loosely-coupled-integration LOST view: TVA-Functional Architecture Principles EIRA concept: eira:ArchitectureBuildingBlock ABB name: elap:loosely-coupled-integration Title: Loosely coupled integration EIF Layer: N/A skos:broader: eira:EuropeanLibraryofArchitecturePrinciplesPrinciple Definition: Digital sovereignty means digital infrastructures, products and services that safeguard European security, strategic assets and interests while respecting European values and requirements. European Institutions and Administrations are representing citizens and businesses and respond to and ensuring the proper development of European society in its most holistic manner. Therefore, there is a need of preventing to spend and depending on external stakeholders to foster the monopoly and vendor lock-in making non-efficient solutions and subject to external agents desires. Digital sovereignty and autonomy imply the adoption of technical alternatives to promote cost-effective, sustainable, independent and secure solutions. Prior assessments of the suitability of these alternatives are strongly recommended, considering each area of implementation and taking into account relevant legal frameworks. Source: C(2022) 4388 final COMMUNICATION TO THE COMMISSION European Commission digital strategy Next generation digital Commission Source reference: https://commission.europa.eu/publications/european-commission-digital-strategy_en Last modification: 2024-01-17 Identifier: http://data.europa.eu/2sa/elap/digital-sovereignty-and-autonomy LOST view: TVA-Functional Architecture Principles EIRA concept: eira:ArchitectureBuildingBlock ABB name: elap:digital-sovereignty-and-autonomy Title: Digital sovereignty and autonomy Additional information: European Institutions and Administrations are representing citizens and businesses and respond to and ensuring the proper development of European society in its most holistic manner. Therefore, there is a need of preventing to spend and depending on external stakeholders to foster the monopoly and vendor lock-in making non-efficient solutions and subject to external agents' desires. The Digital Strategy sets a new vision, addressing digital transformation opportunities of a post-pandemic scenario, and supporting the delivery of the EU’s strategic priorities by 2030. EIF Layer: N/A ABB Specialised: eira:EuropeanLibraryofArchitecturePrinciplesPrinciple Definition: The European Data Sharing principle of consumer protection aims to safeguard the rights and interests of individuals when their personal data is shared. It ensures that individuals have control over their data, are informed about how it will be used, and have the ability to exercise their rights regarding data protection. Source: European Union Source reference: https://edpb.europa.eu/ Last modification: 2024-03-17 Identifier: http://data.europa.eu/dr8/egovera/ConsumerProtectionPrinciple LOST view: Architecture Principles view EIRA concept: eira:ArchitectureBuildingBlock Additional identifier: http://data.europa.eu/dr8/egovera/ConsumerProtectionPrinciple Title: Consumer protection Example: An example of the application of consumer protection in data sharing is when a company collects personal data from its customers for marketing purposes. The company must inform the customers about the specific purposes for which their data will be used, obtain their explicit consent, and provide them with the option to opt-out of such data sharing. Additionally, the company must ensure the security and confidentiality of the data and allow customers to access, correct, or delete their personal information upon request. Additional information: Consumer protection is a fundamental aspect of data sharing in the European Union. It is based on the principles outlined in the General Data Protection Regulation (GDPR) and other relevant legislation. The principle emphasizes the importance of transparency, consent, purpose limitation, data minimization, accuracy, storage limitation, integrity, and confidentiality in protecting the rights of individuals. It also highlights the need for organizations to implement appropriate security measures and provide individuals with mechanisms to exercise their rights, such as the right to access, rectify, and erase their personal data. EIF Layer: N/A ABB Specialised: http://data.europa.eu/dr8/ArchitecturePrinciple ABB name: eira:ConsumerProtectionPrinciple Definition: Signifies the agreement to the processing of personal data related to an individual Source: https://joinup.ec.europa.eu/collection/nifo-national-interoperability-framework-observatory/2-underlying-principles-european-public-services#2.4 Last modification: 2024-01-17 Identifier: http://data.europa.eu/2sa/elap/privacy LOST view: TVA-Functional Architecture Principles EIRA concept: eira:ArchitectureBuildingBlock ABB name: elap:privacy Additional information: Privacy refers to any freely given, specific, informed and unambiguous indication of the data subject's wishes by which he or she, by a statement or by clear affirmative action, signifies agreement to the processing of personal data relating to him or her. Additionally, it refers to ensuring that the vast amounts of citizens' personal data held and processed by public bodies are protected by complying with the applicable legal framework. A relevant aspect to consider when focusing on the application of privacy is full compliance with GDPR Regulation. The European Interoperability Framework is part of the Communication (COM(2017)134) from the European Commission adopted on 23 March 2017. The framework gives specific guidance on how to set up interoperable digital public services. Title: Privacy EIF Layer: N/A skos:broader: http://data.europa.eu/dr8/EuropeanLibraryofArchitecturePrinciplesPrinciple Definition: The implementation of digital public services has a focus on integration, technology, governance or legal. Experience shows that a focused approach is a critical success factor in the implementation of digital public services. An assessment of the context is made prior to the implementation in order to determine the best focus.The priority of the implementation activities is determined by the chosen focus.Use mechanisms provided by the European Commission to plan and align the strategy with real needs. An example is IDPSIO, the IDPSIO (Interoperable Digital Public Services Implementation Orientation) Assessment Tool aims to support digital public service owners in deciding the approach to follow in order to implement their digital public services."" Source: COM(2017) 134 final ANNEX 2 COMMUNICATION FROM THE COMMISSION TO THE EUROPEAN PARLIAMENT, THE COUNCIL, THE EUROPEAN ECONOMIC AND SOCIAL COMMITTEE AND THE COMMITTEE OF THE REGIONS European Interoperability Framework - Implementation Strategy Source reference: https://eur-lex.europa.eu/legal-content/ES/TXT/?uri=CELEX%3A52017DC0134 Last modification: 2024-01-17 Identifier: http://data.europa.eu/2sa/elap/best-fit-public-service-implementation-orientation LOST view: OV-Governance Architecture Principles EIRA concept: eira:ArchitectureBuildingBlock ABB name: elap:best-fit-public-service-implementation-orientation Title: Best fit Public Service Implementation Orientation Additional information: Experience shows that a focused approach is a critical success factor in the implementation of digital public services. EUR-Lex is your online gateway to EU Law. It provides the official and most comprehensive access to EU legal documents. It is available in all of the EU’s 24 official languages and is updated daily EIF Layer: N/A ABB Specialised: eira:EuropeanLibraryofArchitecturePrinciplesPrinciple Definition: Citizen Participation is a principle of European Data Sharing that emphasizes the involvement of citizens in decision-making processes related to data sharing. It recognizes the importance of including citizens in discussions, consultations, and collaborations to ensure transparency, accountability, and democratic governance in data sharing initiatives. Source: European Commission Source reference: https://ec.europa.eu/info/strategy/priorities-2019-2024/europe-fit-digital-age/european-data-strategy_en Last modification: 2024-03-17 Identifier: http://data.europa.eu/dr8/egovera/CitizenParticipationPrinciple LOST view: Architecture Principles view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:CitizenParticipationPrinciple Additional identifier: http://data.europa.eu/dr8/egovera/CitizenParticipationPrinciple Title: Citizen Participation Example: An example of Citizen Participation in practice is when a city government initiates a public consultation process to gather input from residents on the use of data collected through smart city sensors. Citizens are invited to provide feedback, express concerns, and suggest potential uses for the data. This participatory approach allows the city to make informed decisions that reflect the needs and preferences of its citizens, ensuring that data sharing initiatives are transparent, accountable, and beneficial to the community as a whole. Additional information: Citizen Participation promotes the active engagement of individuals, communities, and civil society organizations in shaping data sharing policies, frameworks, and practices. It aims to foster trust, promote inclusivity, and empower citizens to have a say in how their data is collected, used, and shared. By involving citizens, data sharing initiatives can better address societal needs, protect privacy rights, and ensure that data-driven decisions align with public interests. EIF Layer: N/A ABB Specialised: http://data.europa.eu/dr8/ArchitecturePrinciple Definition: The subsidiarity principle requires EU decisions to be taken as closely as possible by the citizen. The proportionality principle limits EU actions to what is necessary to achieve the objectives of the Treaties. One of the implications of the principle is that at a national level, some measures should be put in place to ensure that the specific needs of a specific country are considered and planned within national interoperability frameworks. Source: Subsidiarity and proportionality Underlying Principle (1) of the European Interoperability Framework (EIF) Source reference: https://joinup.ec.europa.eu/collection/nifo-national-interoperability-framework-observatory/2-underlying-principles-european-public-services#2.2 Last modification: 2024-01-17 Identifier: http://data.europa.eu/2sa/elap/subsidiarity-and-proportionality EIRA concept: eira:ArchitectureBuildingBlock ABB name: elap:SubsidiarityAndProportionalityPrinciple Title: Subsidiarity and proportionality EIF Layer: N/A skos:broader: eira:EuropeanLibraryofArchitecturePrinciplesPrinciple Definition: Existing IT systems are reused, before deciding upon buying or even building them. Taxpayers money can only be spent once. Reusing existing systems is a lot cheaper that buying new systems or even building them. In most cases, the requirements of public administrations are not very specific, and existing systems are sufficient to support the processes. It may seem that the costs of building new IT systems can be acceptable, but the costs of the maintenance and support of these systems are often forgotten and are much higher than the cost related to the initial development. When requirements for IT support arise, it is first determined whether systems that provide similar functionality are already available in the organization or otherwise in the market.Requirements that are not supported by existing systems are critically analyzed to determine whether they are really essential.Processes are adapted to existing systems or standard systems that are available in the market, when possible and acceptable.Building new IT systems is only considered a last resort when no existing systems exist or cannot fulfil essential requirements."" Source: Reusability Underlying Principle (4) of the European Interoperability Framework (EIF) Source reference: https://joinup.ec.europa.eu/collection/nifo-national-interoperability-framework-observatory/glossary/term/reusability Last modification: 2024-01-17 Identifier: http://data.europa.eu/2sa/elap/reuse-buy-build LOST view: TVA-Functional Architecture Principles EIRA concept: eira:ArchitectureBuildingBlock ABB name: elap:reuse-buy-build Title: Reuse, before buy, before build EIF Layer: N/A skos:broader: eira:EuropeanLibraryofArchitecturePrinciplesPrinciple Definition: Where possible, public administrations should seek to streamline and simplify their administrative processes by improving them or eliminating any that do not provide public value. Administrative simplification means, where possible, streamlining and simplifying administrative processes by improving them or eliminating anything that does not provide public value. Administrative simplification can help businesses and citizens to reduce the administrative burden of complying with EU legislation or national obligations.Digitisation of public services should take place in accordance with the following concepts:• digital-by-default, whenever appropriate, so that there is at least one digital channel available for accessing and using a given European public service;• digital-first which means that priority is given to using public services via digital channels while applying the multi-channel delivery concept and the no-wrong-door policy, i.e. physical and digital channels co-exist. Simplify processes and use digital channels whenever appropriate for thedelivery of European public services, to respond promptly and with highquality to users’ requests and reduce the administrative burden on publicadministrations, businesses and citizens."" Source: Administrative Simplification Underlying Principle (10) of the European Interoperability Framework (EIF) Source reference: https://joinup.ec.europa.eu/collection/nifo-national-interoperability-framework-observatory/glossary/term/administrative-simplification Last modification: 2024-01-17 Identifier: http://data.europa.eu/2sa/elap/administrative-simplification LOST view: TVA-Functional Architecture Principles EIRA concept: eira:ArchitectureBuildingBlock ABB name: elap:administrative-simplification Title: Administrative Simplification EIF Layer: N/A skos:broader: eira:EuropeanLibraryofArchitecturePrinciplesPrinciple Definition: The principle of self-determination in European Data Sharing emphasizes the individual's right to control their personal data and make informed decisions about its collection, use, and disclosure. It recognizes that individuals should have the autonomy to determine how their data is shared and used by others. Source: European Union Source reference: https://edpb.europa.eu/ Last modification: 2024-03-17 Identifier: http://data.europa.eu/dr8/egovera/SelfDeterminationPrinciple LOST view: Architecture Principles view EIRA concept: eira:ArchitectureBuildingBlock Additional identifier: http://data.europa.eu/dr8/egovera/SelfDeterminationPrinciple Title: Self Determination Example: An example of self-determination in practice is when an individual is presented with clear and understandable choices regarding the collection and use of their personal data. For instance, a website may provide options for users to opt-in or opt-out of certain data processing activities, such as targeted advertising or sharing data with third parties. By giving individuals the ability to exercise their self-determination, they can make informed decisions about their data and protect their privacy. Additional information: Self-determination is a fundamental aspect of data protection and privacy rights. It ensures that individuals have the ability to exercise control over their personal data, including the right to provide or withhold consent for data processing activities. This principle is enshrined in various European data protection laws, such as the General Data Protection Regulation (GDPR), which grants individuals the right to be informed, access, rectify, and erase their personal data. Self-determination also includes the right to object to data processing, restrict processing, and the right to data portability. EIF Layer: N/A ABB Specialised: http://data.europa.eu/dr8/ArchitecturePrinciple ABB name: eira:SelfDeterminationPrinciple Definition: The principle of Fair Competition in European Data Sharing ensures that all participants have equal opportunities and are subject to the same rules and regulations when accessing and utilizing shared data. It promotes a level playing field for businesses and organizations, preventing unfair advantages or monopolistic practices. Source: European Commission Source reference: https://ec.europa.eu/info/strategy/priorities-2019-2024/europe-fit-digital-age/european-data-strategy_en Last modification: 2024-03-17 Identifier: http://data.europa.eu/dr8/egovera/FairCompetitionPrinciple LOST view: Architecture Principles view EIRA concept: eira:ArchitectureBuildingBlock Additional identifier: http://data.europa.eu/dr8/egovera/FairCompetitionPrinciple Title: Fair Competition Example: An example of the application of Fair Competition in European Data Sharing is when a data-sharing platform provides equal access to all participants, regardless of their size or market position. This ensures that startups and smaller businesses have the same opportunities as larger corporations to utilize shared data for product development, market analysis, or improving their services. Additionally, Fair Competition principles may include regulations to prevent data monopolies or anti-competitive behavior, such as prohibiting exclusive data-sharing agreements that limit access for certain competitors. Additional information: Fair Competition is a fundamental principle in the European Data Sharing framework, aiming to foster innovation, encourage market diversity, and prevent anti-competitive behavior. It ensures that data sharing practices do not lead to the creation of monopolies or unfair market advantages for certain entities. By promoting fair competition, the European Union aims to create an environment that benefits both businesses and consumers, fostering economic growth and innovation. EIF Layer: N/A ABB Specialised: http://data.europa.eu/dr8/ArchitecturePrinciple ABB name: eira:FairCompetitionPrinciple Definition: Laws and regulations are technology neutral Regulations tied to a particular technology may quickly become obsolete and require further amendment. Also, technology-specific regulations lead to dependency on specific manufacturers, developers, suppliers or distributors of technology or services. It guarantees freedom of choice by not forcing users into using any specific technology. Source: Technological neutrality and data portability Underlying Principle (5) of the European Interoperability Framework (EIF) Source reference: https://joinup.ec.europa.eu/collection/nifo-national-interoperability-framework-observatory/glossary/term/technological-neutrality-and-data-portability Last modification: 2024-01-17 Identifier: http://data.europa.eu/2sa/elap/technology-neutrality EIRA concept: eira:ArchitectureBuildingBlock ABB name: elap:TechnologyNeutralityPrinciple Title: Technology Neutrality EIF Layer: N/A skos:broader: eira:EuropeanLibraryofArchitecturePrinciplesPrinciple Definition: Security by design refers to one of the prime principles found in any standard and in any practice throughout the whole of IT. Source: https://joinup.ec.europa.eu/collection/nifo-national-interoperability-framework-observatory/2-underlying-principles-european-public-services#2.4 Last modification: 2024-01-17 Identifier: http://data.europa.eu/2sa/elap/security-design LOST view: TVA-Functional Architecture Principles EIRA concept: eira:ArchitectureBuildingBlock ABB name: elap:security-design Additional information: Security by design encompasses the protection of valuable assets, by securing them safely within the boundaries of organizations, taking into account the ownership of the assets. This means that in any circumstance, one has to attend to the valuable property, being 'data' and 'technology' as a whole, both by securing access to (data)assets and by securing the proliferation of data(assets) outside the boundaries, for which one is responsible. Security by design (or secure by design), sometimes abbreviated “SbD,” is a new industry term for a range of security practices built on one fundamental idea — that security should be built into a product by design, instead of being added on later by third-party products and services. The European Interoperability Framework is part of the Communication (COM(2017)134) from the European Commission adopted on 23 March 2017. The framework gives specific guidance on how to set up interoperable digital public services. Title: Security by Design EIF Layer: N/A ABB Specialised: http://data.europa.eu/dr8/EuropeanLibraryofArchitecturePrinciplesPrinciple Definition: The European Data Sharing principle of Inclusion emphasizes the importance of ensuring that all individuals and organizations have equal access to shared data resources. It promotes the idea that data should be made available to a wide range of stakeholders, including citizens, businesses, researchers, and public sector entities, without any discrimination or exclusion based on factors such as nationality, location, or organizational affiliation. Source: European Commission Source reference: https://ec.europa.eu/info/strategy/priorities-2019-2024/europe-fit-digital-age/european-data-strategy_en Last modification: 2024-03-17 Identifier: http://data.europa.eu/dr8/egovera/InclusionPrinciple LOST view: Architecture Principles view EIRA concept: eira:ArchitectureBuildingBlock Additional identifier: http://data.europa.eu/dr8/egovera/InclusionPrinciple Title: Inclusion Example: An example of the application of the Inclusion principle is the creation of open data portals by governments, where they make various datasets available to the public, researchers, and businesses. These portals ensure that data is accessible to anyone interested, enabling the development of innovative applications, research studies, and informed policy-making. Additionally, initiatives promoting data sharing among different organizations, such as public-private partnerships, adhere to the principle of inclusion by allowing equal participation and access to shared data resources. Additional information: Inclusion in data sharing is crucial for fostering innovation, enabling fair competition, and driving societal benefits. It ensures that data is not monopolized by a few entities and encourages collaboration and participation from diverse stakeholders. By promoting inclusivity, the European Data Sharing principle aims to create a level playing field and empower all actors to leverage data for economic growth, scientific advancements, and evidence-based decision-making. EIF Layer: N/A ABB Specialised: http://data.europa.eu/dr8/ArchitecturePrinciple ABB name: eira:InclusionPrinciple Definition: EU Localisation Framework compliance refers to digital public services being compliant and implementing the INSPIRE directive and the different requirements stated in the regulation. The EU Localisation Framework concept consists of a package of case studies, specifications, guidelines, training materials, recommendations and actions required by public administrations and stakeholder communities to facilitate the implementation, use and expansion of INSPIRE in an e-government context. Public Administrations and stakeholders need to follow the different guidelines, implement the specifications and foster training for the understanding of INSPIRE directive. Source: European Union Location Framework (EULF) Source reference: https://inspire.ec.europa.eu/eulf/31 Last modification: 2024-01-17 Identifier: http://data.europa.eu/2sa/elap/eu-localisation-framework-compliance LOST view: TVA-Functional Architecture Principles EIRA concept: eira:ArchitectureBuildingBlock ABB name: elap:eu-localisation-framework-compliance Title: EU Localisation Framework compliance EIF Layer: N/A skos:broader: eira:EuropeanLibraryofArchitecturePrinciplesPrinciple Definition: Metadata and data should be easy to find for both humans and computers Global and universal identification of metadata and data must be achieved by globally unique and persistent identifiers.Enriched (Meta)Data refers to data enrichment, regardless of any specific purpose or use. Metadata needs to be linked to the data that is described. Metadata and data should promote the discovery of digital resources. Data provided must be properly described, ensuring data quality and its discovery. Data and metadata with a high level of standardisation and reuse of already available tools (vocabularies, etc) that allow its discoverability and reuse. Key aspects to make data findable are: Has a persistent identifier, has rich metadata, and is searchable and discoverable online. Source: FAIR Principles Source reference: https://www.go-fair.org/fair-principles/ Last modification: 2024-01-17 Identifier: http://data.europa.eu/2sa/elap/data-findability LOST view: TVA-Functional Architecture Principles EIRA concept: eira:ArchitectureBuildingBlock ABB name: elap:data-findability Title: Data Findability EIF Layer: N/A ABB Specialised: eira:EuropeanLibraryofArchitecturePrinciplesPrinciple Definition: Metadata and data should be well-described so that they can be replicated and/or combined in different settings. Reusability is the central goal of FAIR and is usually the trigger for the introduction of data management and FAIR in companies. In principle, achieving F, A and I should achieve most of R - but there is another important aspect of the reusability principle that needs to be resolved. When designing data collection processes, reusability beyond the original purpose must be considered. It is usually extremely difficult to make data that is not FAIR reusable after the fact. Data reusability must be in place from the beginning, i.e. context and tacit knowledge must be built in from the start. Otherwise, there is a risk that datasets will be found and analysed under false assumptions, leading to a disruption of projects and sometimes a reluctance of researchers to share their data with others. Data reusability must be in place from the beginning, i.e. context and tacit knowledge must be built in from the start. Otherwise, there is a risk that datasets will be found and analysed under false assumptions, leading to a disruption of projects and sometimes a reluctance of researchers to share their data with others.Mechanisms that ensure the data can be reused by other stakeholders are relevant, for this, two aspects to take into account are well-documented and clear licence and provenance information. "" Source: FAIR Principles Source reference: https://www.go-fair.org/fair-principles/ Last modification: 2024-01-17 Identifier: http://data.europa.eu/2sa/elap/data-reusability LOST view: TVA-Functional Architecture Principles EIRA concept: eira:ArchitectureBuildingBlock ABB name: elap:data-reusability Title: Data Reusability EIF Layer: N/A ABB Specialised: eira:EuropeanLibraryofArchitecturePrinciplesPrinciple Definition: The design and implementation of sufficient mechanisms to attain full visibility on the effective realisation of public services, based on public policies, by putting in place processes and procedures that provide accountability to stakeholders. Digital public services are based on public policies, their context and constraints. Bounded on that fact, organisations develop their strategies and roadmaps accordingly, which implies the provision of funds and efforts to develop effective and efficient public services. The economic and technical efforts need to be monitored and tracked to ensure that policies are implemented without additional effort. At that point is where public administrations need to put mechanisms to follow-up on implementations and the attainment of public policy objectives. Evaluate the effectiveness and efficiency of different interoperabilitysolutions and technological options considering user needs, proportionality and balance between costs and benefits"" Source: Assessment of Effectiveness and Efficiency Underlying Principle (12) of the European Interoperability Framework (EIF) Source reference: https://joinup.ec.europa.eu/collection/nifo-national-interoperability-framework-observatory/glossary/term/assessment-effectiveness-and-efficiency Last modification: 2024-01-17 Identifier: http://data.europa.eu/2sa/elap/convergence-control-public-policy-goals-attainment EIRA concept: eira:ArchitectureBuildingBlock ABB name: elap:ConvergenceControlOnPublicPolicyGoalsAttainmentPrinciple Title: Convergence control on public policy goals attainment EIF Layer: N/A ABB Specialised: eira:EuropeanLibraryofArchitecturePrinciplesPrinciple Definition: European Library of Architecture Principles (ELAP) ABB is a set of principles that aim to support interoperability and standardization in eGoverment across the EU. Source: ELAP Source reference: https://joinup.ec.europa.eu/collection/common-assessment-method-standards-and-specifications-camss/solution/elap Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/EuropeanLibraryOfArchitecturePrinciplesPrinciple LOST view: Legal view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:EuropeanLibraryOfArchitecturePrinciplesPrinciple Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): ELAP transparency principle in the EIF context refers to: Enabling visibility inside the administrative environment of a public administration. This is about allowing other public administrations, citizens, and businesses to view and understand administrative rules, processes, 11 data, services, and decision-making. Ensuring availability of interfaces with internal information systems. Public administrations operate a large number of what are often heterogeneous and disparate information systems in support of their internal processes. Interoperability depends on ensuring the availability of interfaces to these systems and the data they handle. In turn, interoperability facilitates reuse of systems and data, and enables these to be integrated into larger systems. Securing the right to the protection of personal data, by respecting the applicable legal framework for the large volumes of personal data of citizens, held and managed by Public administrations. https://joinup.ec.europa.eu/collection/common-assessment-method-standards-and-specifications-camss/solution/elap/distribution/elap-catalogue-v100xlsx Interoperability Saliency: The European Library of Architecture Principles (ELAP) ABB is salient for governance interoperability due to it establishes the principles and framework to ensure interoperability at the European level. Also, the European Library of Architecture Principles ABB is salient for organizational interoperability due to it establishes requirements and business processes to enable interoperability between public services. Additional information: The European Library of Architecture Principles (ELAP) ABB is a set of principles intended to direct government organizations in initiating changes and implementing IT projects. Particularly when designing new or modified services, it is necessary to make visible how the principles are implemented and which considerations are made in this regard. The apply-or-explain principle applies here, whereby deviations are permitted provided that they are substantiated and recorded with good arguments so that they can be revisited at a later stage. This prevents important matters from being overlooked. Interoperability Dimension: Governance IoP Viewpoint: EIRA Ontology viewpoint Additional identifier: http://data.europa.eu/dr8/EuropeanLibraryOfArchitecturePrinciplesPrinciple EIF Layer: N/A Definition: The European Data Sharing Principles are a set of guidelines established by the European Union to promote the responsible and secure sharing of data among organizations. These principles aim to foster innovation, maximize the value of data, and ensure privacy and data protection. Source: European Commission Source reference: https://ec.europa.eu/ Additional information: The European Data Sharing Principles were developed in alignment with the General Data Protection Regulation (GDPR) and other relevant data protection laws. They emphasize the importance of transparency, legal compliance, and accountability when sharing data. The principles encourage organizations to adopt fair and non-discriminatory data sharing practices, implement appropriate security measures, and establish clear governance frameworks for data sharing initiatives. By following these principles, the European Union seeks to create a data-sharing ecosystem that benefits both businesses and individuals while maintaining high standards of data protection. Example: An example application of the European Data Sharing Principles is a consortium of healthcare providers sharing anonymized patient data for medical research purposes. The principles ensure that the data is handled securely and in compliance with data protection laws. The healthcare providers implement technical measures to de-identify the data, establish data access controls, and define data usage agreements. Researchers can then access the shared data for scientific studies while protecting patient privacy and maintaining the trust of the individuals whose data is being shared. eira:iopDimension: Governance IoP LOST view: Architecture Principles view eira:iopSaliency: Interoperability is a key aspect of the European Data Sharing Principles. It ensures that data can be effectively shared and utilized across different systems, organizations, and sectors. By promoting interoperability, the principles aim to break down data silos, facilitate data exchange, and foster collaboration. This interoperability saliency enables seamless integration and analysis of diverse datasets, leading to enhanced decision-making, innovation, and societal benefits. Identifier: http://data.europa.eu/dr8/egovera/EuropeanDataSharingPrinciplesPrinciple ABB name: egovera:EuropeanDataSharingPrinciplesPrinciple EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-07-07 dct:identifier: http://data.europa.eu/dr8/egovera/EuropeanDataSharingPrinciplesPrinciple Definition: Users have an integrated experience of digital public services Users should be optimally supported in their tasks. They should not be bothered by the fact that multiple organizations, processes or applications are needed to support these tasks. Users of digital public services experience one user interface which supports them in the execution of their tasks, and which feels like one application.Users are not confronted with duplicate steps or data entry in the execution of their tasks.Users need to only log in once to execute their tasks."" Source: eID Building Block of DIGITAL Europe Source reference: https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/2019/07/02/Improving+the+user+experience+of+cross-border+eID Last modification: 2024-01-17 Identifier: http://data.europa.eu/2sa/elap/integrated-horizontal-user-experience EIRA concept: eira:ArchitectureBuildingBlock ABB name: elap:IntegratedHorizontalUserExperiencePrinciple Title: Integrated Horizontal User Experience EIF Layer: N/A skos:broader: eira:EuropeanLibraryofArchitecturePrinciplesPrinciple Definition: Records are preserved and made long-term accessible. Legislation requires that decisions and data are stored and can be accessed for a specified time. This includes all data and information in the electronic form held by public administrations for the purpose of documenting procedures and decisions. The goal is to ensure that records and other forms of information keep their legibility, reliability and integrity and can be accessed as long as needed subject to security and privacy provisions. Source: Preservation of information Underlying Principle (12) of the European Interoperability Framework (EIF) Source reference: https://joinup.ec.europa.eu/collection/nifo-national-interoperability-framework-observatory/2-underlying-principles-european-public-services#2.12 Last modification: 2024-01-17 Identifier: http://data.europa.eu/2sa/elap/preservation-information EIRA concept: eira:ArchitectureBuildingBlock ABB name: elap:PreservationOfInformationPrinciple Title: Preservation of information EIF Layer: N/A ABB Specialised: eira:EuropeanLibraryofArchitecturePrinciplesPrinciple Definition: Datasets metadata machine-readable format, vocabularies reused, and reference to other datasets and their metadata. Data format should be readable for machines without the need for specialised or ad hoc algorithms, translators, or mappings. Data does not exist in isolation but is highly dependent upon other data that is available from other parties. Data should also be reused, when possible, to prevent collecting the same data twice and introducing duplication, with the risk of inconsistency. Controlled vocabularies define the terms in a specific domain, standardising their interpretation. These concepts are the foundation for data, providing definitions and meaning to them. It is important for users of data to have access to these definitions, so they can correctly interpret the data. The usage of standardised methods for the representation of metadata (RDF, OWL, DAM+OIL, JSON LD). In the metadata of datasets, references are made to the metadata of other datasets that the dataset depends upon. The data model of the dataset refers to the data model and the specific data elements and definitions that are reused from other datasets. The data itself includes identifiers to data in other datasets that the data depends upon.Relevant controlled vocabularies that exist for the domain that is covered by a specific dataset are determined. Important terms that are not defined by existing controlled vocabularies are defined in a new controlled vocabulary. The controlled vocabulary is published in a standardized format in a location that can easly be found by the target audience. The controlled vocabulary and the concepts that it describes have globally unique and persistent identifiers, so they can easily be referred to."" Source: FAIR principles Source reference: https://www.go-fair.org/fair-principles/ Last modification: 2024-01-17 Identifier: http://data.europa.eu/2sa/elap/data-interoperability LOST view: TVA-Functional Architecture Principles EIRA concept: eira:ArchitectureBuildingBlock ABB name: elap:data-interoperability Title: Data Interoperability EIF Layer: N/A ABB Specialised: eira:EuropeanLibraryofArchitecturePrinciplesPrinciple Definition: Code of ethics compliance refers to the expression of important values and standards that are also to be found in the law, but not only aspects related to legally-binding issues. A code of ethics is a written set of expectations that an organization has for its employees to conduct business in an honest manner. Ethics are values and principles that govern behaviour or conduct. Apart from legislation, the European foundational text \"Treaty on the Functioning of the European Union\" sets up the different terms and relevant aspects for the proper function of the European Union. All public services provided by public administrations under European Union must be aligned and fully compliant with European Union values. All initiatives and services need to be aligned and compliant with European Union values. Source: European Ombudsman Source reference: https://www.ombudsman.europa.eu/en/speech/en/49379;https://ec.europa.eu/commission/presscorner/detail/en/IP_22_452 Last modification: 2024-01-17 Identifier: http://data.europa.eu/2sa/elap/code-ethics-compliance EIRA concept: eira:ArchitectureBuildingBlock ABB name: elap:CodeOfEthicsCompliancePrinciple Title: Code of ethics compliance EIF Layer: N/A skos:broader: eira:EuropeanLibraryofArchitecturePrinciplesPrinciple Definition: Enabling visibility inside the administrative environment of a public administration. Enabling visibility within the administrative environment of a public administration. It is about enabling other public administrations, citizens and businesses to view and understand administrative rules, processes, data, services and decision-making processes. Transparency at this stage requires public administrations to align with legal texts promoting and ensuring accountability from European institutions to citizens and businesses. Public organisations at the organisational level, need to include standardised processes that allow users to understand information, rules, data, services or the decision-making process of any organisation. "" Source: Transparency Underlying Principle (3) of the European Interoperability Framework (EIF) Source reference: https://joinup.ec.europa.eu/collection/nifo-national-interoperability-framework-observatory/2-underlying-principles-european-public-services Last modification: 2024-01-17 Identifier: http://data.europa.eu/2sa/elap/transparency-of-the-administrative-environment LOST view: SV-Functional Architecture Principles EIRA concept: eira:ArchitectureBuildingBlock ABB name: elap:transparency-of-the-administrative-environment Title: Transparency of the administrative environment EIF Layer: N/A ABB Specialised: eira:EuropeanLibraryofArchitecturePrinciplesPrinciple Definition: Ensure the evolution of society and eGovernment by implementing means for the achievement of the purpose, specifically for inclusion and equitative public service, resilience towards crises and efficient and effective innovation. NWS is a hierarchy-driven system within a hierarchy-market-network space. This NWS (based and driven by hierarchy) then moved to one of the normative reform models. The Neo-Weberian-State approach is focused an aimed to ensure three main core principles, that are specifically relevant to the development of eGovernment and societies: inclusive and equitable service delivery, resilient crises governance, and effective innovation for government and society. The application of the principle or the work towards the approach is a key enabler for digital and healthy societies, where users and the overall society is taken into account, and put on the focus on the development of Digital Public Services. Public administrations need to promote and implement policies, and legal instruments that guide the creation of inclusive and equitable service delivery, resilient crises governance, and effective innovation for government and society. Source: \"The neo-Weberian state: From ideal type model to reality?\" by UCL Institute for Innovation and Public Purpose Source reference: https://www.ucl.ac.uk/bartlett/public-purpose/sites/bartlett_public_purpose/files/bouckaert_g._2022_the_neo-weberian_state_from_ideal_type_model_to_reality_0.pdf Last modification: 2024-01-17 Identifier: http://data.europa.eu/2sa/elap/neo-weberian-state-approach LOST view: TVA-Governance Architecture Principles EIRA concept: eira:ArchitectureBuildingBlock ABB name: elap:neo-weberian-state-approach Title: Neo-Weberian-State approach (NWS) Additional information: NWS is a hierarchy-driven system within a hierarchy-market-network space. This NWS (based and driven by hierarchy) then moved to one of the normative reform models. The Neo-Weberian-State approach is focused an aimed to ensure three main core principles, that are specifically relevant to the development of eGovernment and societies: inclusive and equitable service delivery, resilient crises governance, and effective innovation for government and society. The application of the principle or the work towards the approach is a key enabler for digital and healthy societies, where users and the overall society is taken into account, and put on the focus on the development of Digital Public Services. The UCL Institute for Innovation and Public Purpose is focused on the development and research of how digital platforms and services can improve societies. EIF Layer: N/A skos:broader: eira:EuropeanLibraryofArchitecturePrinciplesPrinciple Definition: Data Sovereignty refers to the ability of stakeholders involved in the delivery of public services to have full control over the shared data. The concept of data sovereignty is becoming more and more relevant while digital transformation advances. Digital Sovereignty is relevant in the context of digital public services because allows the control of which data is shared between parties. Under an environment compliant with data sovereignty, all stakeholders can manage the data they aim to provide. Therefore, when planning and designing public services, data sovereignty is a pillar to guarantee the rights and obligations of the different parties. Nowadays, data spaces are gaining relevance and public administrations are putting efforts to focus on interoperability through the establishment of domain-specific data spaces. In this field, data sovereignty is specifically relevant and needs to be taken into account. Organisations behind digital pubic services should ensure and put in place the required mechanism to ensure that parties involved in the services (public administrations, citizens, and businesses) have the capability to control the data shared. Additionally, mechanisms to detect when relevant and private data is about to be leaked. Security and privacy are narrowly related and need to be handled accordingly to ensure compliance with the principle. Source: \"Towards a Reference Enterprise Architecture to enforce Digital Sovereignty in International Data Spaces\". University of Twente Source reference: https://ris.utwente.nl/ws/portalfiles/portal/285489087/_Firdausy_2022_Towards_a_Reference_Enterprise_Architecture_to_enforce_Digital_Sovereignty_in_International_Data_Spaces.pdf Last modification: 2024-01-17 Identifier: http://data.europa.eu/2sa/elap/data-sovereignty LOST view: TVA-Functional Architecture Principles EIRA concept: eira:ArchitectureBuildingBlock ABB name: elap:data-sovereignty Title: Data Sovereignty Additional information: The concept of data sovereignty is becoming more and more relevant while digital transformation advances. Digital Sovereignty is relevant in the context of digital public services because allows the control of which data is shared between parties. Under an environment compliant with data sovereignty, all stakeholders can manage the data they aim to provide. Therefore, when planning and designing public services, data sovereignty is a pillar to guarantee the rights and obligations of the different parties. Nowadays, data spaces are gaining relevance and public administrations are putting efforts to focus on interoperability through the establishment of domain-specific data spaces. In this field, data sovereignty is specifically relevant and needs to be taken into account. The University of Twente, specifically its Faculty of Behavioural, Management and Social Science is leading working groups and investigations on how e-Government can leverage new data paradigms can help to enhance the digital transformation and the relevance of digital public services by implementing Data Spaces. EIF Layer: N/A ABB Specialised: eira:EuropeanLibraryofArchitecturePrinciplesPrinciple Definition: Architecture Principle ABB is a Principle that enables general rules and guidelines for the use and deployment of all IT resources and assets across the enterprise. Source: TOGAF 9.2 The Open Group Source reference: https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap20.html#:~:text=Architecture%20Principles%20define%20the%20underlying,for%20making%20future%20IT%20decisions Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/ArchitecturePrinciplePrinciple LOST view: Legal view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:ArchitecturePrinciplePrinciple Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): The European Innovation Partnership on Smart Cities and Communities (EIP SCC) is a stakeholder driven initiative stimulated and supported by the European Commission. The EIP SCC has defined key priority areas which will be addressed including the architecture principle of Capabilities. Capabilities are the center element of the architectures to ensure that a common ground is easy to be found.(https://ec.europa.eu/research/participants/documents/downloadPublic?documentIds=080166e5b9a18c76&appId=PPGMS) Interoperability Saliency: The Architecture Principle ABB is salient for governance interoperability due to it lays the architectural framework to elaborate public services. Also, the Architecture Principle ABB is salient for organizational interoperability due to it establishes the requirements to sustain the business processes for enabling public services to exchange data. Additional information: The architecture Principle reflects the level of consensus among the various elements of the enterprise, and form the basis for making future IT decisions. Interoperability Dimension: Governance IoP Viewpoint: EIRA Ontology viewpoint Additional identifier: http://data.europa.eu/dr8/ArchitecturePrinciplePrinciple EIF Layer: N/A Definition: Data portability is ensured. The functioning of the digital single market requires data to be easily transferable among different systems to avoid lock-in and support the frthe movement of data. This requirement relates to data portability - the ability to move and reuse data easily among different applications and systems, which becomes even more challenging in cross-border scenarios. Source: Technological neutrality and data portability Underlying Principle (5) of the European Interoperability Framework (EIF) Source reference: https://joinup.ec.europa.eu/collection/nifo-national-interoperability-framework-observatory/glossary/term/technological-neutrality-and-data-portability Last modification: 2024-03-17 Identifier: http://data.europa.eu/2sa/elap/data-portability LOST view: TVA-Functional Architecture Principles EIRA concept: eira:ArchitectureBuildingBlock ABB name: elap:data-portability Title: Data portability EIF Layer: N/A skos:broader: eira:EuropeanLibraryofArchitecturePrinciplesPrinciple Definition: Data Altruism is a principle of European Data Sharing that promotes the voluntary sharing of data for the common good. It encourages individuals and organizations to share their data with the aim of benefiting society as a whole, rather than for personal or commercial gain. Source: European Commission Source reference: https://ec.europa.eu/info/strategy/priorities-2019-2024/europe-fit-digital-age/european-data-strategy_en Last modification: 2024-03-17 Identifier: http://data.europa.eu/dr8/egovera/DataAltruismPrinciple LOST view: Architecture Principles view EIRA concept: eira:ArchitectureBuildingBlock Additional identifier: http://data.europa.eu/dr8/egovera/DataAltruismPrinciple Title: Data Altruism Example: An example of data altruism is when a healthcare organization shares anonymized patient data with researchers to improve medical treatments and find new cures. By voluntarily sharing this data, the organization contributes to the advancement of medical knowledge and benefits society as a whole. Additional information: Data Altruism emphasizes the importance of sharing data in a responsible and ethical manner. It encourages data owners to consider the potential societal impact of their data and make it available for research, innovation, and public interest purposes. By promoting data altruism, the European Union aims to foster collaboration, innovation, and the development of data-driven solutions to address societal challenges. EIF Layer: N/A ABB Specialised: http://data.europa.eu/dr8/ArchitecturePrinciple ABB name: eira:DataAltruismPrinciple Definition: The European Data Sharing principle of Fundamental Rights ensures that data sharing practices respect and protect the fundamental rights of individuals within the European Union. It emphasizes the importance of upholding privacy, data protection, and other fundamental rights while sharing data. Source: European Commission Source reference: https://ec.europa.eu/info/strategy/priorities-2019-2024/europe-fit-digital-age/european-data-strategy_en Last modification: 2024-03-17 Identifier: http://data.europa.eu/dr8/egovera/FundamentalRightsPrinciple LOST view: Architecture Principles view EIRA concept: eira:ArchitectureBuildingBlock Additional identifier: http://data.europa.eu/dr8/egovera/FundamentalRightsPrinciple Title: Fundamental Rights Example: An example of applying the Fundamental Rights principle is when a company shares customer data with a third-party service provider. The company must ensure that the data sharing agreement respects the privacy rights of its customers, complies with data protection regulations, and safeguards against any potential discrimination or misuse of the shared data. Additional information: The principle of Fundamental Rights is based on the understanding that data sharing should not compromise the rights of individuals, including their right to privacy, protection of personal data, freedom of expression, non-discrimination, and other fundamental rights enshrined in the European Union's Charter of Fundamental Rights. It aims to strike a balance between the benefits of data sharing and the protection of individual rights. EIF Layer: N/A ABB Specialised: http://data.europa.eu/dr8/ArchitecturePrinciple ABB name: eira:FundamentalRightsPrinciple Definition: A full life cycle cost of ownership (including retirement costs) should form part of the business case. At a critical stage for sustainable development in terms of climate change, and excess use of resources (economic, natural resources, etc), there is a need for the public administrations to use and establish relevant policies that help the reduction of general waste. Public administrations are the first link of the chain and need to be the example for society and businesses on taking care of the whole life cycle for technology products. Therefore, when planning and designing public services, this aspect needs to be included (from the design and implementation to the retirement) When implementing and retiring elements related to the provision of digital public services, public administrations shall include and create policies that ensure the lifecycle of infrastructures, applications services and equipment, is considered and extended to ensure the minimum waste in terms of sustainability. An example regarding this last topic spotted is, for instance, the application of policies to ensure that no additional costs (economic, social and environmental) rise when renewing the computer fleet."" Source: How the EU wants to achieve a circular economy by 2050 in News European Parliament Source reference: https://www.europarl.europa.eu/news/en/headlines/society/20210128STO96607/how-the-eu-wants-to-achieve-a-circular-economy-by-2050 Last modification: 2024-01-17 Identifier: http://data.europa.eu/2sa/elap/care-cradle-grave LOST view: OV-Governance Architecture Principles EIRA concept: eira:ArchitectureBuildingBlock ABB name: elap:care-cradle-grave Title: Care from cradle to grave Additional information: At a critical stage for sustainable development in terms of climate change, and excess use of resources (economic, natural resources, etc), there is a need for the public administrations to use and establish relevant policies that help the reduction of general waste. Public administrations are the first link of the chain and need to be the example for society and businesses on taking care of the whole life cycle for technology products. Therefore, when planning and designing public services, this aspect needs to be included (from the design and implementation to the retirement) How the EU wants to achieve a circular economy by 2050 EIF Layer: N/A ABB Specialised: eira:EuropeanLibraryofArchitecturePrinciplesPrinciple Definition: Public services are transformed into digital public services Making public services digital makes them more accessible, reduces administrative burdens and time and allows faster responses to individuals and organizations. The European Commission has also set out a strategy for the digital transformation of its own services. Digital channels are also the Commission’s preferred way to communicate. Laws and regulations are adapted to enable digital services when they lead to barriers to digital transformation.Public administrations seek to transform existing public services into digital public services.Digital public services can easily be found and accessed by users on the web sites of public administrations.Digital public services that are focused on government-to-business are made accessible through automated systems interfaces, such as API."" Source: C(2022) 4388 final COMMUNICATION TO THE COMMISSION European Commission digital strategy Next generation digital Commission Source reference: https://commission.europa.eu/publications/european-commission-digital-strategy_en Last modification: 2024-01-17 Identifier: http://data.europa.eu/2sa/elap/digital-first LOST view: TVA-Functional Architecture Principles EIRA concept: eira:ArchitectureBuildingBlock ABB name: elap:digital-first Title: Digital First EIF Layer: N/A ABB Specialised: eira:EuropeanLibraryofArchitecturePrinciplesPrinciple Definition: Innovation entails rethinking organisations and processes and changing behaviour so that public services are delivered more efficiently to people. Implemented well, eGovernment enables citizens, enterprises and organisations to carry out their business with the government more easily, more quickly and at a lower cost.Investing in research and innovation is investing in Europe’s future. It helps us to compete globally and preserve our unique social model. It improves the daily lives of millions of people here in Europe and around the world, helping to solve some of our biggest societal challenges. Innovation implies iterative and active thinking in public administrations and digital public services delivery. This includes several aspects and different layers. At the organisational layer, monitoring and looking for strategies to create new public services according to new technologies.At the technical level, implement new approaches and technologies aligned with public policies and their objectives."" Source: OPEN EUROPE Policies, Reforms and Achievements in EI Science and Innovation 2014-2019 Source reference: https://european-union.europa.eu/priorities-and-actions/actions-topic/research-and-innovation_en Last modification: 2024-01-17 Identifier: http://data.europa.eu/2sa/elap/innovation EIRA concept: eira:ArchitectureBuildingBlock ABB name: elap:InnovationPrinciple Title: Innovation EIF Layer: N/A ABB Specialised: eira:EuropeanLibraryofArchitecturePrinciplesPrinciple Definition: Social participation refers to Promoting Civic Participation and Transparency of Government Decision-Making Processes covering policies concerning ICT. The usage of digital environments can promote new kinds of sociability, support, and usability or revive certainly lost facets of social ties.The construction of more effective public services, as well as new kinds of communication and interaction between citizens and the various levels of government, can all be facilitated by the use of digital tools. Even more public involvement in various levels of local management processes is possible with their use. These fresh working alliances also contribute to the legitimacy and increased transparency of public activity. Some examples of social participation are:• E-democracy• E-participation• Government-to-citizen (G2C)• Citizen-to-government (C2G)• Citizen-to-citizen (C2C)• Open governance partnership• Grass-root activism and social networking• Political campaigns• Online media• I-voting• Mechanisms: e-petitions, online consultation and crowd-sourcing platforms etc. The implications of social participation are related to the creation and implementation of policies that include as the backbone, the citizens and businesses. Additionally, to policies that govern, it is relevant that public administrations implement tools that foster, enable and ensure stakeholders participation. "" Source: Digital Democracy of European Citizen Action Service (ECAS) Source reference: https://ecas.org/digital-democracy/ Last modification: 2024-01-17 Identifier: http://data.europa.eu/2sa/elap/social-participation EIRA concept: eira:ArchitectureBuildingBlock ABB name: elap:SocialParticipationPrinciple Title: Social participation EIF Layer: N/A ABB Specialised: eira:EuropeanLibraryofArchitecturePrinciplesPrinciple Definition: Evidence-based Public Policies are policies designed and periodically reviewed looking at experimental evidences and incontrovertible data. The primary goal is to improve the reliability of advice concerning the efficiency and effectiveness of policy settings and possible alternatives.There are three crucial enabling factors that underpin modern conceptions of evidence-based policy (EBP): high-quality information basis on relevant topic areas, cohorts of professionals with skills in data analysis and policy evaluation, and political incentives for utilising evidence-based analysis and advice in governmental decision-making processes. Public administrations should foster the creation of public policies by: - Promoting the creation and collection of information and knowledge on relevant topics for the administration; - Training and ensuring the evolution and aggregation of professionals knowledgable in all domains that public administrations should legislate, and elaborate policies; - Actively promoting the creation of public policies based on the analysis and collection of evidence.Additionally, public administrations must put in place mechanisms to review ongoing public policies but also the whole public policy life cycle. "" Source: Evidence-based policy (EBP) Source reference: https://www.researchgate.net/publication/242709855_2_Evidence-based_policy_principles_and_requirements Last modification: 2024-01-17 Identifier: http://data.europa.eu/2sa/elap/evidence-based-public-policy EIRA concept: eira:ArchitectureBuildingBlock ABB name: elap:EvidenceBasedPublicPolicyPrinciple Title: Evidence based Public Policy EIF Layer: N/A ABB Specialised: eira:EuropeanLibraryofArchitecturePrinciplesPrinciple Definition: In the context of interoperable public services, the concept of openness mainly relates to data, specifications and software. This principle is based on three pillars: the openness of public administrations data, the openness of the software used and implemented and the openness of standards and specifications used to develop digital public services. Refers to the idea that all public data should be freely available for use and reuse by others unless restrictions apply e.g. for the protection of personal data, confidentiality, or intellectual property rights. Also, refers to ensuring a level playing field for open-source software and demonstrating active and fair consideration of using open-source software, taking into account the total cost of ownership of the solution.And last but not least, give preference to open specifications, taking due account of the coverage of functional needs, maturity and market support and innovation."" Source: Openness Underlying Principle (2) of the European Interoperability Framework (EIF) Source reference: https://joinup.ec.europa.eu/collection/nifo-national-interoperability-framework-observatory/2-underlying-principles-european-public-services#2.3 Last modification: 2024-01-17 Identifier: http://data.europa.eu/2sa/elap/openness EIRA concept: eira:ArchitectureBuildingBlock ABB name: elap:OpennessPrinciple Title: Openness EIF Layer: N/A skos:broader: eira:EuropeanLibraryofArchitecturePrinciplesPrinciple Definition: Digital public services enable accountability of public administrations It is generally accepted that public administrations should be held accountable for what they do. However, accountability is a multi-faceted term encompassing transparency, liability, controllability, responsibility, and responsiveness. Digital public services can provide functionality that supports people and organisations in taking accountability. Public administrations provide digital public services that give access to information about their actions, the results of their actions and the decisions taken in these actions. Publisher: ELAP Source: Public Administration Review (Yale School of Management) Source reference: https://onlinelibrary.wiley.com/doi/abs/10.1111/j.1540-6210.2005.00434.x Last modification: 2024-01-17 Identifier: http://data.europa.eu/2sa/elap/accountability EIRA concept: eira:ArchitectureBuildingBlock ABB name: elap:AccountabilityPrinciple Title: Accountability EIF Layer: N/A ABB Specialised: eira:EuropeanLibraryofArchitecturePrinciplesPrinciple Definition: The European Commission's digital transformation must be based on the identification of cross-organisational needs and the development of internal partnerships. Strong and reliable relationships with other EU institutions and beyond, should be fostered in order to share resources and remain at the forefront of the latest technological trends. Specific approaches in technology such as user-centric, data-driven and agile trends must be pursued. The creation of MoU and organisational agreements is required to ensure that public Institutions are aware of their role and the role of others. Source: C(2022) 4388 final COMMUNICATION TO THE COMMISSION European Commission digital strategy Next generation digital Commission Source reference: https://commission.europa.eu/publications/european-commission-digital-strategy_en Last modification: 2024-01-17 Identifier: http://data.europa.eu/2sa/elap/digital-partnership LOST view: TVA-Functional Architecture Principles EIRA concept: eira:ArchitectureBuildingBlock ABB name: elap:digital-partnership Title: Digital Partnership Additional information: Strong and reliable relationships with other EU institutions and beyond, should be fostered in order to share resources and remain at the forefront of the latest technological trends. Specific approaches in technology such as user-centric, data-driven and agile trends must be pursued. The Digital Strategy sets a new vision, addressing digital transformation opportunities of a post-pandemic scenario, and supporting the delivery of the EU’s strategic priorities by 2030. EIF Layer: N/A ABB Specialised: eira:EuropeanLibraryofArchitecturePrinciplesPrinciple Definition: Proactiveness refers to proactive services, which are public services that a public institution delivers following its own initiatives. European institutions and public administrations throughout Europe, are reference actors and roles that can lead the environment on digital public services and also on the use of available data for the creation of innovative services taking as basis life, business events and circumstances. There is an increasing amount of data from citizens, businesses and other stakeholders that European institutions can leverage to think and create digital public services according to users needs (citizens or businesses). For the implementation of proactiveness on digital public services, making proactive public services, there are implications at different levels such as:At the legal level, ensure that the data used is treated and managed following the correspondent legal clauses;At the organisational level, ensure that digital capabilities are instantiated by services aligned with user needs and following the correspondent agreement between parties to ensure data sovereignty;At the legal interoperability, ensure that data is properly described and following the current approaches for semantic interoperability; and,At the technical level, ensure that proper technical application and technology services are available to reuse and deliver those services. "" Source: Joinup Source reference: https://joinup.ec.europa.eu/ Last modification: 2024-01-17 Identifier: http://data.europa.eu/2sa/elap/proactiveness EIRA concept: eira:ArchitectureBuildingBlock ABB name: elap:ProactivenessPrinciple Title: Proactiveness EIF Layer: N/A skos:broader: eira:EuropeanLibraryofArchitecturePrinciplesPrinciple Definition: The sustainability principle in European Data Sharing emphasizes the long-term viability and environmental impact of data sharing practices. It promotes the responsible use of data resources to ensure their availability for future generations while minimizing any negative ecological consequences. Source: European Commission Source reference: https://ec.europa.eu/info/strategy/priorities-2019-2024/europe-fit-digital-age/european-data-strategy_en Last modification: 2024-03-17 Identifier: http://data.europa.eu/dr8/egovera/SustainabilityPrinciple LOST view: Architecture Principles view EIRA concept: eira:ArchitectureBuildingBlock Additional identifier: http://data.europa.eu/dr8/egovera/SustainabilityPrinciple ABB name: eira:SustainabilityPrinciple Title: Sustainability Example: An example of applying the sustainability principle in data sharing is the implementation of energy-efficient data centers that utilize renewable energy sources. By reducing energy consumption and carbon emissions associated with data storage and processing, organizations can contribute to a more sustainable data infrastructure. Additionally, adopting data preservation strategies, such as long-term archiving and data lifecycle management, ensures the availability and usability of valuable data resources for future research and innovation. Additional information: Sustainability in data sharing involves adopting practices that prioritize the preservation and efficient utilization of data resources. This principle encourages organizations to consider the environmental impact of their data sharing activities, such as minimizing energy consumption, reducing carbon emissions, and promoting the use of renewable energy sources. It also emphasizes the importance of long-term data preservation, ensuring that data remains accessible and usable for future generations. By integrating sustainability into data sharing practices, organizations can contribute to a more environmentally conscious and resilient digital ecosystem. EIF Layer: N/A ABB Specialised: http://data.europa.eu/dr8/ArchitecturePrinciple Definition: European digital public services are multilingual."@en, "European public services can potentially be used by anyone in any Member State. So multilingualism needs to be carefully considered when designing them. Citizens across Europe often have problems accessing and using digital public services if these are not available in the languages they speak. Source: Multilingualism Underlying Principle (9) of the European Interoperability Framework (EIF) Source reference: https://joinup.ec.europa.eu/collection/nifo-national-interoperability-framework-observatory/glossary/term/multilingualism Last modification: 2024-03-17 Identifier: http://data.europa.eu/2sa/elap/multilingualism EIRA concept: eira:ArchitectureBuildingBlock ABB name: elap:MultilingualismPrinciple Title: Multilingualism EIF Layer: N/A skos:broader: eira:EuropeanLibraryofArchitecturePrinciplesPrinciple Definition: The design of digital public services is centred around their users. Users of European public services are meant to be any public administration, citizen or business accessing and benefiting from the use of these services. Users’ needs should be considered when determining which public services should be provided and how they should be delivered. Therefore, as far as possible, user needs and requirements should guide the design and development of public services. A multi-channel service delivery approach, meaning the availability of alternative channels, physical and digital, to access a service, is an important part of public service design, as users may prefer different channels depending on the circumstances.A single point of contact should be made available to users, to hide internal administrative complexity and facilitate access to public services, e.g. when multiple bodies have to work together to provide a public service.Users’ feedback should be systematically collected, assessed and used to design new public services and to improve existing ones further.As far as possible, under the legislation in force, users should be able to provide data once only, and administrations should be able to retrieve and share this data to serve the user, in accordance with data protection rules.Users should be asked to provide only the information that is absolutely necessary to obtain a given public service."" Source: User-Centricity Underlying Principle (6) of the European Interoperability Framework (EIF) Source reference: https://joinup.ec.europa.eu/collection/nifo-national-interoperability-framework-observatory/glossary/term/user-centricity Last modification: 2024-01-17 Identifier: http://data.europa.eu/2sa/elap/user-centricity EIRA concept: eira:ArchitectureBuildingBlock ABB name: elap:User-centricityPrinciple Title: User-centricity EIF Layer: N/A skos:broader: eira:EuropeanLibraryofArchitecturePrinciplesPrinciple Definition: EU Legislation Compliance is the property of (national/local) legislation to be coherent or to implement European legislation. Member States play a key role in ensuring EU law is implemented correctly and in a timely manner. This is essential for people and businesses to optimally benefit from commonly agreed rules. A compliance assessment of EU Directives must be carried out in two stages:(1) timely and systematic check whether Member States have transposed Union law;(2) a timely and systematic conformity check of national transposing measures against the relevant Union legislation (correct transposition). While Member States are responsible for the timely and accurate transposition of directives as well as the correct application of the entire acquis, the Commission has to monitor the Member States’ efforts and ensure that their legislation complies with Union law."" Source: COM(2017) 134 final ANNEX 2 COMMUNICATION FROM THE COMMISSION TO THE EUROPEAN PARLIAMENT, THE COUNCIL, THE EUROPEAN ECONOMIC AND SOCIAL COMMITTEE AND THE COMMITTEE OF THE REGIONS European Interoperability Framework - Implementation Strategy Source reference: https://eur-lex.europa.eu/resource.html?uri=cellar:2c2f2554-0faf-11e7-8a35-01aa75ed71a1.0017.02/DOC_3&format=PDF Last modification: 2024-01-17 Identifier: http://data.europa.eu/2sa/elap/eu-legislation-compliance EIRA concept: eira:ArchitectureBuildingBlock ABB name: elap:EULegislationCompliancePrinciple Title: EU Legislation Compliance EIF Layer: N/A skos:broader: eira:EuropeanLibraryofArchitecturePrinciplesPrinciple Definition: Service orientation is a way of thinking in terms of services and service-based development and the outcomes of services. Being user-centred or remaining \"user-led,\" is possible with a service-oriented strategy. It entails offering services that employ the best technological solutions to provide better results. By making this change, the organization will put user demands and goals at the centre of its vision, culture, and operations. After then, make sure that everyone supports it and owns it so that decisions and technology are driven by user demands.A service-oriented strategy entails developing an IT platform made up of numerous systems, each one tailored to carry out particular tasks. You can change one aspect of a systems functionality with a tech stack made up of separate components without changing the operation of the entire system. Certain components can be digitalized more quickly because of this function fragmentation, which also offers a distribution strategy that allows for independently distributed functions. Communication with external programs is also made possible by separate systems where each software tool is designed to carry out a specific task using a well-defined interface.There are a variety of technologies that can be applied to this service orientation approach such as SOAP, REST API and GraphQL. At the organisational level, public administrations need to establish the proper agreements that allow collaboration and common mechanisms to provide relevant information through the desired Service Oriented Architecture. At the technical level, the organisations in charge of implementing and delivery of digital public services will need to determine which is the best approach to fit their needs. There are different approaches such as SAP, RESTApi or GraphQL, taking into account the relevant aspects of the services, the organisation responsible for the service should select the more sustainable and efficient way of implementing the SOA approach. "" Source: Open Group Source reference: https://web.archive.org/web/20160819141303/http://opengroup.org/soa/source-book/soa/soa.htm Last modification: 2024-01-17 Identifier: http://data.europa.eu/2sa/elap/service-orientation EIRA concept: eira:ArchitectureBuildingBlock ABB name: elap:ServiceOrientationPrinciple Title: Service Orientation EIF Layer: N/A skos:broader: eira:EuropeanLibraryofArchitecturePrinciplesPrinciple Definition: Ensuring availability of interfaces with internal information systems. Public administrations operate a large number of what are often heterogeneous and disparate information systems in support of their internal processes. Interoperability depends on ensuring the availability of interfaces to these systems and the data they handle. In turn, interoperability facilitates the reuse of systems and data and enables these to be integrated into larger systems. Incorporation of horizontal approaches to ensure the availability of services, applications and systems working towards harmonising how information is available, organised and in standardized formats that allow data exchange without limiting it. Source: Transparency Underlying Principle (3) of the European Interoperability Framework (EIF) Source reference: https://joinup.ec.europa.eu/collection/nifo-national-interoperability-framework-observatory/2-underlying-principles-european-public-services Last modification: 2024-01-17 Identifier: http://data.europa.eu/2sa/elap/transparency-of-internal-information-systems LOST view: TVA-Functional Architecture Principles EIRA concept: eira:ArchitectureBuildingBlock ABB name: elap:transparency-of-internal-information-systems Title: Transparency of internal information systems Additional information: Public administrations operate a large number of what are often heterogeneous and disparate information systems in support of their internal processes. Interoperability depends on ensuring the availability of interfaces to these systems and the data they handle. In turn, interoperability facilitates the reuse of systems and data and enables these to be integrated into larger systems. The European Interoperability Framework is part of the Communication (COM(2017)134) from the European Commission adopted on 23 March 2017. The framework gives specific guidance on how to set up interoperable digital public services. EIF Layer: N/A ABB Specialised: eira:EuropeanLibraryofArchitecturePrinciplesPrinciple Definition: The assessment of the effective realisation of public services, based on public policies, by evaluating various technological solutions when striving to ensure the effectiveness and efficiency of European public services. Digital public services should be the result of public policies based on real constructed and relevant societal needs. Therefore, it is relevant to ensure efficiency and effectiveness in the delivery of public services. For this reason, public administration has the duty of evaluating and ensuring that the resources are dedicated to the implementation and delivery of digital public services that are aligned with public policies and their objectives. In addition to the alignment of digital public services with public policies goal, there is the need to assess the efficiency of the service and the elements involved, to ensure that the investment done is proportionate to the societal needs and the relevance and value the service provides Evaluate the effectiveness and efficiency of different interoperability solutions and technological options considering user needs, proportionality and balance between costs and benefits. Source: Assessment of Effectiveness and Efficiency Underlying Principle (12) of the European Interoperability Framework (EIF) Source reference: https://joinup.ec.europa.eu/collection/nifo-national-interoperability-framework-observatory/glossary/term/assessment-effectiveness-and-efficiency Last modification: 2024-01-17 Identifier: http://data.europa.eu/2sa/elap/convergence-assurance-public-policy-goals-attainment EIRA concept: eira:ArchitectureBuildingBlock ABB name: elap:ConvergenceAssuranceOnPublicPolicyGoalsAttainmentPrinciple Title: Convergence assurance on public policy goals attainment EIF Layer: N/A skos:broader: eira:EuropeanLibraryofArchitecturePrinciplesPrinciple Definition: Citizens and businesses provide public administrations data only once Requesting the data multiple times leads to an unnecessary administrative burden for citizens and businesses. It also leads to multiple administrations of the same data, with a high risk of inconsistency and low data quality. It is essential that the data that public administrations use is of good quality, in order to prevent errors and delays in processes and provide high-quality services. There is a central metadata administration of all the datasets that public administration bodies have available for reuse.Public administration bodies first determine whether specific data elements are available for reuse before they decide to collect them.Data that can be reused from other public administrations are not requested from citizens or businesses but simply referred to."" Source: Once Only Principle of DIGITAL Europe Source reference: https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/Once+Only+Principle Last modification: 2024-01-17 Identifier: http://data.europa.eu/2sa/elap/once-only EIRA concept: eira:ArchitectureBuildingBlock ABB name: elap:OnceOnlyPrinciple Title: Once Only EIF Layer: N/A skos:broader: eira:EuropeanLibraryofArchitecturePrinciplesPrinciple Definition: Archivability is an IT non-functional requirement that refers to the ability of a system to store and retrieve data or information over a long period of time. This requirement is important for systems that deal with critical data or information that needs to be preserved for legal, regulatory, or historical purposes. Archivability ensures that data is stored in a format that can be accessed and retrieved easily, even after a long period of time, and that the data remains accurate and complete. It also ensures that the system can handle large amounts of data and that the data is stored securely to prevent unauthorized access or tampering. Source: TOGAF Source reference: https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap03.html Additional information: Archivability is a non-functional requirement that pertains to the ability of a system to store and preserve data for future reference or use. According to the TOGAF specification, guidelines, and documentation, archivability is a critical aspect of enterprise architecture, particularly in the context of data management and governance. The archivability non-functional requirement is closely related to other requirements such as data retention, data integrity, and data security. It involves ensuring that data is stored in a format that is easily retrievable and accessible, and that it remains intact and uncorrupted over time. This requirement is particularly important for organizations that are required to comply with regulatory or legal requirements, as it ensures that data can be retrieved and presented as evidence if necessary. To meet the archivability non-functional requirement, enterprise architects must consider a range of factors, including the type of data being stored, the format in which it is stored, the storage medium used, and the length of time for which the data needs to be retained. They must also consider the potential risks associated with data loss or corruption, and implement appropriate measures to mitigate these risks. In practice, meeting the archivability non-functional requirement may involve implementing a range of technologies and processes, such as data backup and recovery systems, data archiving solutions, and data retention policies. It may also involve working closely with stakeholders across the organization to ensure that data is managed and stored in a way that meets their needs and requirements. Overall, the archivability non-functional requirement is a critical aspect of enterprise architecture, and one that must be carefully considered and managed to ensure the long-term viability and success of an organization. Example: Archivability: The system must be able to store and retrieve data for a minimum of 10 years, with the ability to export data in a standard format for long-term storage and retrieval. LOST view: Digital Solution Non-Functional Requirements Catalogue view Identifier: http://data.europa.eu/dr8/egovera/ArchivabilityRequirement EIRA traceability: eira:DigitalSolutionNonFunctionalRequirementRequirement ABB name: egovera:ArchivabilityRequirement EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-05-16 dct:identifier: http://data.europa.eu/dr8/egovera/ArchivabilityRequirement dct:title: Archivability Non-Functional Requirement Definition: Detail-Level Architecture Building Block Architecture is a Requirement formulating specific low-level capabilities of a software system. It should provide a structured and consistent approach to develop and maintain the system. This approach is based on breaking the system into smaller and manegable pieces (building blocks) and combined can create a robust and reliable system. Source: European Commission, ISA Programme Source reference: https://ec.europa.eu/isa2/sites/default/files/eif_brochure_final.pdf Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Stating that the Digital Public Service should use REST API to interface itself with other services and that it should use HTTPS protocol to guarantee data privacy is considered a detail-level architecture requirement for the design of software. Source:(https://www.brainkart.com/article/Functional-Requirements---Software-Architectures_11271/#:~:text=The%20following%20are%20examples%20of%20explicit%20architectural%20requirements%3A,Functionality%208%20Usability%209%20Reliability%20More%20items...%20) LOST view: Legal view Interoperability saliency: Detail-Level Architecture Building Block ABB is salient for semantic and technical interoperability because it determine (i) the interfaces to interact with the data (ii) the data exchange mechanism and (iii) the data privacy instruments to access and share the data. Identifier: http://data.europa.eu/dr8/Detail-LevelArchitectureRequirement eira:ID: ABB485 ABB name: eira:Detail-LevelArchitectureRequirement EIRA concept: EIRA_ONTOLOGY_CLASS Last modification: 2023-09-01 Definition: Binding Instrument ABB is a Business Object involving an obligation, which is available to the European institutions to carry out their tasks. Source: Eur-Lex Source reference: http://eur-lex.europa.eu/summary/glossary/community_legal_instruments.html Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/BindingInstrumentRequirement LOST view: Legal view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:BindingInstrumentRequirement Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Directive (EU) 2019/790 of the European Parliament and of the Council of 17 April 2019 on copyright and related rights in the Digital Single Market and amending Directives 96/9/EC and 2001/29/EC (Text with EEA relevance.). http://data.europa.eu/eli/dir/2019/790/oj Interoperability Saliency: The Binding Instrument ABB is relevant for legal and governance interoperability as, by being a specialisation of the Legal Act, it makes mandatory the implementation of the policy (and therefore the underlying interoperability implications). Additional information: Additional Information: The European binding instruments listed in Article 288 of the Treaty on the Functioning of the European Union are: The European binding instruments listed in Article 288 of the Treaty on the Functioning of the European Union are: - regulations: these are binding in their entirety and directly applicable in all EU countries; - directives: these bind the EU countries as to the results to be achieved; they have to be transposed into the national legal framework and thus leave margin for manoeuvre as to the form and means of implementation; - decisions: these are fully binding on those to whom they are addressed; - recommendations and opinions: these are non-binding, declaratory instruments. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/BindingInstrumentRequirement EIF Layer: Legal Definition: Fault tolerance is an IT non-functional requirement that refers to the ability of a system to continue functioning even in the event of hardware or software failures. This means that the system should be able to detect and recover from errors or failures without causing any disruption to the user experience. Fault tolerance is important for critical systems that cannot afford to fail, such as those used in healthcare, finance, and transportation. It involves redundancy, backup systems, and failover mechanisms to ensure that the system remains operational even in the face of unexpected events. Source: TOGAF Source reference: https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap03.html Additional information: According to the TOGAF specification, fault tolerance is a non-functional requirement that refers to the ability of a system to continue operating in the event of a failure or error. This means that the system should be able to detect and recover from faults or errors without causing any disruption to the overall performance or availability of the system. To achieve fault tolerance, the system should be designed with redundancy and failover mechanisms that can automatically switch to backup components or systems in the event of a failure. This can include redundant hardware components, such as servers, storage devices, and network connections, as well as software components, such as load balancers, clustering, and replication. In addition, the system should be able to detect faults and errors in real-time, using monitoring and alerting mechanisms that can notify system administrators or operators of any issues. This can include automated monitoring tools that can detect performance issues, security breaches, or other types of errors that can impact the system's availability or performance. Overall, fault tolerance is a critical non-functional requirement for any system that requires high availability and reliability, such as mission-critical applications, financial systems, or healthcare systems. By designing systems with fault tolerance in mind, organizations can ensure that their systems can continue operating even in the face of unexpected failures or errors, minimizing downtime and ensuring business continuity. Example: One example of the IT non-functional requirement 'Fault tolerance' is in the aviation industry. The flight control systems of an aircraft must be designed to be fault-tolerant, meaning that they can continue to operate even if one or more components fail. This is critical for ensuring the safety of passengers and crew in the event of a system failure. The system must be able to detect and isolate faults, and then continue to operate using redundant components or backup systems. LOST view: Digital Solution Non-Functional Requirements Catalogue view Identifier: http://data.europa.eu/dr8/egovera/FaultToleranceRequirement EIRA traceability: eira:DigitalSolutionNonFunctionalRequirementRequirement ABB name: egovera:FaultToleranceRequirement EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-05-16 dct:identifier: http://data.europa.eu/dr8/egovera/FaulttoleranceRequirement dct:title: Fault tolerance Non-Functional Requirement Definition: Legal Act ABB is a Business Object formalising a set of rules on a subject potentially including requirements concerning digital public services. Source: European Union Law Source reference: https://eur-lex.europa.eu/summary/glossary/legislative_acts.html Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/LegalActRequirement LOST view: Legal view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:LegalActRequirement Synonym: Legal Instrument Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): The COMMISSION REGULATION (EU) 2018/1881 of 3 December 2018 amending Regulation (EC) No 1907/2006 of the European Parliament and of the Council on the Registration, Evaluation, Authorisation and Restriction of Chemicals (REACH) as regards Annexes I, III,VI, VII, VIII, IX, X, XI, and XII to address nanoforms of substances (https://eur-lex.europa.eu/legal-content/EN/TXT/?qid=1544102387245&uri=CELEX:32018R1881) is an example of an SBB implementing a Legal Act ABB. Interoperability Saliency: The Legal Act ABB is salient for legal interoperability because it helps establish legal rules by ensuring compatible legal/juridical certainty in the exchange of information. Additional information: The granularity of the requirements might be of high level or detail level. Requirements of high-level granularity contain generic/abstract functional requirements like principles and/or recommendations with considerable degrees for transposition/execution and of not binding nature. On the other side, requirements of detail-level granularity imply a limited degree for transposition/execution and they contain specific/concrete functionalities, solution components, data, procedures, and/or technical specifications or standards to be used. EU legal acts are legislative or non-legislative acts adopted by the European institutions (Article 288 TFEU). With the entry into force of the Treaty of Lisbon on 1 December 2009. The names "European Union" or "EU" have replaced "European Community", "Community" or "EC". Interoperability Dimension: Structural IoP Viewpoint: Interoperability Privacy viewpoint Additional identifier: http://data.europa.eu/dr8/LegalActRequirement EIF Layer: Legal Definition: Availability is a non-functional requirement that refers to the ability of a system or application to be accessible and operational at all times. It is a measure of the system's reliability and the ability to provide uninterrupted service to users. This requirement is critical for systems that are used in mission-critical environments, such as healthcare, finance, and transportation. High availability is achieved through redundancy, fault tolerance, and disaster recovery mechanisms that ensure that the system can continue to function even in the event of hardware or software failures. Source: TOGAF Source reference: https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap03.html Additional information: According to the TOGAF specification, Availability is a non-functional requirement that refers to the ability of a system or application to be accessible and usable by authorized users at all times. This requirement is critical for ensuring that the system or application is always available for use, regardless of any potential disruptions or failures. To meet the Availability requirement, the system or application must be designed and implemented with a high degree of resilience, fault tolerance, and redundancy. This may involve the use of redundant hardware, software, and network components, as well as the implementation of backup and recovery procedures to ensure that data is not lost in the event of a failure. Additionally, the system or application must be designed to handle high levels of traffic and usage, without experiencing performance degradation or downtime. This may involve the use of load balancing and other performance optimization techniques to ensure that the system can handle peak loads without impacting availability. Overall, the Availability requirement is critical for ensuring that the system or application is always accessible and usable by authorized users, and must be carefully considered and addressed during the design and implementation phases of the project. Example: One example of an IT non-functional requirement for availability could be for a banking system to have a 99.99% uptime, meaning that the system should be available for use by customers 99.99% of the time. This requirement ensures that customers can access their accounts and perform transactions at any time without experiencing downtime or system failures. LOST view: Digital Solution Non-Functional Requirements Catalogue view Identifier: http://data.europa.eu/dr8/egovera/AvailabilityRequirement EIRA traceability: eira:DigitalSolutionNonFunctionalRequirementRequirement ABB name: egovera:AvailabilityRequirement EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-05-16 dct:identifier: http://data.europa.eu/dr8/egovera/AvailabilityRequirement dct:title: Availability Non-Functional Requirement Definition: EIRA viewpoint ABB is a Requirement providing a perspective with specific stakeholders concern in mind. The EIRA© provides several viewpoints that conform to EIRA© views. (1) A specification of the conventions for a particular kind of architecture view. Source: TOGAF Source reference: (https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap03.html#tag_03_18) Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Highlevel viewpoint - The EIRA© Highlevel viewpoint models an introductory overview of the focal Architecture Building Blocks of each view. It aligns the EIRA© with the service delivery model described within the Interoperability Maturity Model (IMM), and the New European Interoperability Framework (EIF) conceptual model for public services. The ABBs included in the high-level viewpoint represent the points that link the EIRA©’s views enabling traceability between their different Architecture Building Blocks. They are not necessarily mandatory but should always be considered by a user of the EIRA© when executing one of its use cases. Identifier: http://data.europa.eu/dr8/EIRAViewpointRequirement eira:ID: ABB605 ABB name: eira:EIRAViewpointRequirement Last modification: 2022-20-01 Definition: Scalability is an important non-functional requirement for any IT system, which refers to the ability of the system to handle increasing amounts of workload or users without compromising its performance or stability. A scalable system should be able to accommodate growth in data volume, traffic, and user base, by adding more resources or nodes to the system, without causing any downtime or degradation in response time. Scalability is critical for ensuring that the system can meet the demands of the business, adapt to changing requirements, and provide a seamless user experience. Source: TOGAF Source reference: https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap03.html Additional information: According to the TOGAF specification, scalability is a non-functional requirement that refers to the ability of a system to handle increasing amounts of work or traffic without experiencing a decrease in performance or stability. This requirement is important for systems that are expected to grow or expand over time, as it ensures that the system can handle the increased workload without compromising its functionality or reliability. Scalability can be achieved through a variety of techniques, including horizontal scaling (adding more servers or nodes to distribute the workload), vertical scaling (adding more resources to a single server or node), and load balancing (distributing the workload across multiple servers or nodes). It is important to consider scalability early in the design process, as it can impact the overall architecture and infrastructure of the system. To ensure that scalability is achieved, it is important to establish performance metrics and benchmarks, and to regularly test and monitor the system to identify any bottlenecks or areas for improvement. Additionally, the system should be designed with modularity and flexibility in mind, so that it can be easily adapted and expanded as needed. Overall, scalability is a critical non-functional requirement for any system that is expected to grow or evolve over time, and should be carefully considered and addressed in the design and implementation phases of the system development lifecycle. Example: An example of the IT non-functional requirement 'Scalability' could be a web application that needs to handle a large number of concurrent users. The application should be able to scale up or down based on the number of users accessing it at any given time. This means that the application should be able to handle a sudden surge in traffic without crashing or slowing down. Additionally, the application should be able to add more resources such as servers or storage as needed to accommodate the increased traffic. LOST view: Digital Solution Non-Functional Requirements Catalogue view Identifier: http://data.europa.eu/dr8/egovera/ScalabilityRequirement EIRA traceability: eira:DigitalSolutionNonFunctionalRequirementRequirement ABB name: egovera:ScalabilityRequirement EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-05-16 dct:identifier: http://data.europa.eu/dr8/egovera/ScalabilityRequirement dct:title: Scalability Non-Functional Requirement Definition: Accountability is an IT non-functional requirement that refers to the ability of a system to track and record the actions of users and processes. This requirement ensures that all activities within the system can be traced back to their source, allowing for transparency and responsibility. Accountability is essential for compliance with regulations and standards, as well as for detecting and preventing fraudulent or malicious activities. It also helps to build trust and confidence in the system by providing a clear audit trail of all actions taken. Source: TOGAF Source reference: https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap03.html Additional information: According to the TOGAF specification, Accountability is a non-functional requirement that refers to the ability to trace and audit the actions and decisions made by a system or its users. This requirement ensures that the system can be held responsible for its actions and that there is a clear record of who made what decision and when. To meet this requirement, the system must have the ability to log and track all user actions and system events. This includes the ability to record user login and logout times, the actions taken by users while logged in, and any system events that occur during operation. The system must also be able to generate reports and audit trails that can be used to trace the actions and decisions made by the system and its users. In addition, the system must provide mechanisms for controlling access to sensitive data and functionality. This includes the ability to restrict access to certain features or data based on user roles and permissions. The system must also provide mechanisms for enforcing data privacy and security policies to ensure that sensitive data is protected from unauthorized access or disclosure. Overall, the Accountability non-functional requirement is critical for ensuring that the system is transparent and can be held responsible for its actions. By providing the ability to trace and audit user actions and system events, the system can be used with confidence and trust. Example: One example of the IT non-functional requirement 'Accountability' could be ensuring that all actions taken by users on a system are logged and traceable to the individual user. This would allow for accountability in the event of any unauthorized or malicious activity on the system. LOST view: Digital Solution Non-Functional Requirements Catalogue view Identifier: http://data.europa.eu/dr8/egovera/AccountabilityRequirement EIRA traceability: eira:DigitalSolutionNonFunctionalRequirementRequirement ABB name: egovera:AccountabilityRequirement EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-05-16 dct:identifier: http://data.europa.eu/dr8/egovera/AccountabilityRequirement dct:title: Accountability Non-Functional Requirement Definition: Authentication is a non-functional requirement that ensures that only authorized users can access a system or application. It involves verifying the identity of the user through various means such as passwords, biometric identification, or security tokens. Authentication is crucial for maintaining the security and integrity of a system, as it prevents unauthorized access and protects sensitive information from being compromised. It also helps to ensure accountability and traceability by keeping a record of user activities. Source: TOGAF Source reference: https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap03.html Additional information: According to the TOGAF specification, Authentication is a non-functional requirement that refers to the process of verifying the identity of a user or system. It is a critical aspect of security and is necessary to ensure that only authorized users or systems can access the system or application. The Authentication non-functional requirement can be further broken down into several sub-requirements, including: 1. Identification - The process of identifying a user or system based on a unique identifier such as a username, email address, or IP address. 2. Authentication Mechanisms - The methods used to verify the identity of a user or system, such as passwords, biometric authentication, or two-factor authentication. 3. Authorization - The process of granting or denying access to specific resources or functions based on the authenticated user's permissions. 4. Audit Trail - The ability to track and record all authentication attempts and actions taken by authenticated users or systems. 5. Security - The requirement to ensure that authentication mechanisms are secure and cannot be easily bypassed or compromised. Overall, the Authentication non-functional requirement is critical to ensuring the security and integrity of a system or application and should be carefully considered and implemented in accordance with industry best practices and standards. Example: An example of the IT non-functional requirement 'Authentication' could be that a user must provide a valid username and password to access a secure system or application. This ensures that only authorized users are able to access sensitive information or perform certain actions within the system. Additionally, the system may require multi-factor authentication, such as a security token or biometric verification, to further enhance security and prevent unauthorized access. LOST view: Digital Solution Non-Functional Requirements Catalogue view Identifier: http://data.europa.eu/dr8/egovera/AuthenticationRequirement EIRA traceability: eira:DigitalSolutionNonFunctionalRequirementRequirement ABB name: egovera:AuthenticationRequirement EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-05-16 dct:identifier: http://data.europa.eu/dr8/egovera/AuthenticationRequirement dct:title: Authentication Non-Functional Requirement Definition: Legality is an IT non-functional requirement that ensures that the software or system complies with all applicable laws, regulations, and standards. It is important to ensure that the system does not violate any legal or regulatory requirements, such as data privacy laws, copyright laws, or industry-specific regulations. Failure to comply with these requirements can result in legal and financial consequences for the organization. Therefore, it is crucial to ensure that the system is designed and developed in accordance with all applicable legal and regulatory requirements. Source: TOGAF Source reference: https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap03.html Additional information: According to the TOGAF specification, guidelines, and documentation, the non-functional requirement of 'Legality' refers to the compliance of the IT system with legal and regulatory requirements. This requirement ensures that the system adheres to all applicable laws, regulations, and standards, including data protection laws, intellectual property laws, and industry-specific regulations. The Legality requirement also includes the need for the system to be auditable and transparent, allowing for regulatory compliance checks and audits. The system must also provide appropriate documentation and reporting capabilities to demonstrate compliance with legal and regulatory requirements. In addition, the Legality requirement also encompasses the need for the system to be secure and protect sensitive data from unauthorized access or disclosure. This includes the implementation of appropriate security measures, such as encryption, access controls, and monitoring, to ensure that the system meets legal and regulatory requirements for data protection. Overall, the Legality requirement is critical for ensuring that the IT system operates within the boundaries of the law and meets all applicable legal and regulatory requirements. Failure to meet this requirement can result in legal and financial penalties, reputational damage, and loss of customer trust. Example: One example of an IT non-functional requirement related to legality could be ensuring compliance with data privacy laws such as GDPR or CCPA. This could include requirements for data encryption, user consent for data collection and processing, and data retention policies. LOST view: Digital Solution Non-Functional Requirements Catalogue view Identifier: http://data.europa.eu/dr8/egovera/LegalityRequirement EIRA traceability: eira:DigitalSolutionNonFunctionalRequirementRequirement ABB name: egovera:LegalityRequirement EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-05-16 dct:identifier: http://data.europa.eu/dr8/egovera/LegalityRequirement dct:title: Legality Non-Functional Requirement Definition: Key Interoperability Enabler ABB is a Requirement enabling the efficient and effective delivery of public services across administrations. Source: European Commission, ISA Programme Source reference: (https://ec.europa.eu/isa2/sites/default/files/eif_brochure_final.pdf) Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): The European Digital Identity will be available to EU citizens, residents, and businesses who want to identify themselves or provide confirmation of certain personal information. It can be used for both online and offline public and private services across the EU. The Digital Identity is a key interoperability enabler because it enables the efficient and effective delivery of Identification.(https://ec.europa.eu/info/strategy/priorities-2019-2024/europe-fit-digital-age/european-digital-identity_en#:~:text=Digital%20Identity%20for%20all%20Europeans%20The%20European%20Digital,offline%20public%20and%20private%20services%20across%20the%20EU.) Identifier: http://data.europa.eu/dr8/KeyInteroperabilityEnablerRequirement eira:ID: ABB618 ABB name: eira:KeyInteroperabilityEnablerRequirement Last modification: 2022-23-01 Definition: EIRA view ABB is a Requirement containing a graphical notation of the EIRA ontology. The EIRA consists of several architecture views (1) , including one view for each of the EIF interoperability levels. (1) An architecture view is a representation of a system from the perspective of a related set of concerns. Source: TOGAF Source reference: (https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap03.html#tag_03_17) Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Legal View - The Legal view models the most salient public policy development enablers and implementation instruments that shall be considered in order to support the End to End design of interoperable digital public services. Identifier: http://data.europa.eu/dr8/EIRAViewRequirement eira:ID: ABB606 ABB name: eira:EIRAViewRequirement Last modification: 2022-23-01 Definition: Interoperability Requirement ABB is a Requirement being formulated as an agreed normative statement in functional terms on a legal, organisational, semantic, or technical attribute of a To-Be European Public Service Source: European Commission, ISA Programme Source reference: (https://ec.europa.eu/isa2/sites/default/files/eif_brochure_final.pdf) Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Ewshopp: - Interoperability requirements are for facilitating access to and integration of data within the project. These requirements cover data formats, vocabularies and shared systems of identifiers useful in data modelling to facilitate data enrichment tasks, as well as data manipulation functionalities needed to support them.(https://ec.europa.eu/research/participants/documents/downloadPublic?documentIds=080166e5b4c5d61e&appId=PPGMS) Identifier: http://data.europa.eu/dr8/InteroperabilityRequirement eira:ID: ABB346 ABB name: eira:InteroperabilityRequirement Last modification: 2022-23-01 Definition: Legal clauses ABB is a Requirement that refers to specific points or topics that permit to specify a legal document. Source: European Comision Source reference: https://commission.europa.eu/law/law-making-process/types-eu-law_en Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/LegalClausesRequirement LOST view: Legal view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:LegalClausesRequirement Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Clause 6 - Description of the transfer(s): The details of the transfer(s), and in particular the categories of personal data that are transferred and the purpose(s) for which they are transferred, are specified in Annex I.B. (http://data.europa.eu/eli/dec_impl/2021/914/oj) Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/LegalClausesRequirement EIF Layer: Legal Definition: Durability is an IT non-functional requirement that refers to the ability of a system or application to withstand and recover from failures, errors, or disruptions. It ensures that the system can maintain its functionality and data integrity even in the face of unexpected events such as power outages, hardware failures, or network disruptions. Durability is critical for systems that handle sensitive or mission-critical data, as any loss or corruption of data can have severe consequences. To achieve durability, systems may use techniques such as data replication, backup and recovery, and fault tolerance. Source: TOGAF Source reference: https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap03.html Additional information: Durability is a non-functional requirement that refers to the ability of a system to maintain its functionality and performance over time, even in the face of adverse conditions such as hardware failures, power outages, or other disruptions. This requirement is important for systems that are critical to the operation of an organization or that handle sensitive or valuable data. According to the TOGAF specification, durability is one of the key quality attributes that must be considered when designing and implementing an enterprise architecture. This requirement is closely related to other non-functional requirements such as reliability, availability, and maintainability, which together form the basis of a system's overall performance and effectiveness. To ensure that a system meets the durability requirement, architects and designers must consider a range of factors, including the robustness of hardware components, the resilience of software applications, and the effectiveness of backup and recovery procedures. They must also consider the impact of environmental factors such as temperature, humidity, and power fluctuations, and design systems that can withstand these conditions without compromising performance or functionality. In addition to these technical considerations, architects and designers must also consider the organizational and operational factors that can affect durability. This includes factors such as training and support for system users, maintenance and repair procedures, and disaster recovery planning. Overall, the durability requirement is a critical aspect of enterprise architecture design, and must be carefully considered and addressed in order to ensure the long-term success and effectiveness of a system. Example: One example of the IT non-functional requirement 'Durability' could be for a database system to maintain data integrity and availability even in the event of hardware failures or power outages. This means that the system should be able to recover quickly and efficiently from any disruptions or failures without losing any data or causing any downtime for users. The durability requirement ensures that the system can handle unexpected events and maintain its functionality over time. LOST view: Digital Solution Non-Functional Requirements Catalogue view Identifier: http://data.europa.eu/dr8/egovera/DurabilityRequirement EIRA traceability: eira:DigitalSolutionNonFunctionalRequirementRequirement ABB name: egovera:DurabilityRequirement EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-05-16 dct:identifier: http://data.europa.eu/dr8/egovera/DurabilityRequirement dct:title: Durability Non-Functional Requirement Definition: Usability is a non-functional requirement that refers to the ease of use and learnability of a software system. It encompasses factors such as user interface design, navigation, and accessibility, and aims to ensure that the system is intuitive and efficient for users to interact with. Usability is important for ensuring user satisfaction, reducing errors and frustration, and ultimately improving the overall user experience. Source: TOGAF Source reference: https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap03.html Additional information: According to the TOGAF specification, Usability is a non-functional requirement that refers to the ease of use and learnability of a system or application. It encompasses various aspects such as user interface design, navigation, and user experience. Usability is an important consideration for any system or application as it directly impacts user satisfaction and productivity. A system that is difficult to use or navigate can lead to frustration and errors, which can ultimately result in decreased productivity and user adoption. To ensure that a system meets the usability requirement, it is important to consider the needs and expectations of the users. This can be achieved through user research and testing, as well as incorporating user feedback throughout the development process. Usability can also be measured through various metrics such as task completion time, error rates, and user satisfaction surveys. These metrics can help identify areas for improvement and ensure that the system is meeting the needs of its users. Overall, the usability non-functional requirement is an important consideration for any system or application and should be addressed throughout the development process to ensure user satisfaction and productivity. Example: One example of the IT non-functional requirement 'Usability' could be that the software application should have a clear and intuitive user interface that is easy to navigate and understand, even for users who are not technically proficient. This could include features such as clear labeling of buttons and menus, consistent design elements throughout the application, and the ability to customize the interface to suit individual user preferences. Additionally, the application should be responsive and fast, with minimal lag or delays when performing tasks or loading data. LOST view: Digital Solution Non-Functional Requirements Catalogue view Identifier: http://data.europa.eu/dr8/egovera/UsabilityRequirement EIRA traceability: eira:DigitalSolutionNonFunctionalRequirementRequirement ABB name: egovera:UsabilityRequirement EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-05-16 dct:identifier: http://data.europa.eu/dr8/egovera/UsabilityRequirement dct:title: Usability Non-Functional Requirement Definition: Capability ABB is a Requirement that refers to the ability to develop, deploy, and maintain IoP applications and services. This includes knowledge and skills in areas such as software development, network engineering, data analytics, and cybersecurity Source: European Comission Source reference: https://digital-strategy.ec.europa.eu/en/library/definition-artificial-intelligence-main-capabilities-and-scientific-disciplines Identifier: http://data.europa.eu/dr8/CapabilityRequirement ABB name: eira:CapabilityRequirement Last modification: 2022-23-01 Definition: Consistency is an important non-functional requirement in IT systems that refers to the uniformity and coherence of data and processes across different components of the system. It ensures that the system behaves predictably and reliably, and that users can trust the accuracy and completeness of the information they receive. Consistency can be achieved through the use of standardized formats, protocols, and interfaces, as well as through rigorous testing and quality assurance procedures. It is particularly important in distributed systems, where data and processes may be spread across multiple servers or networks. Source: TOGAF Source reference: https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap03.html Additional information: According to the TOGAF specification, guidelines, and documentation, the non-functional requirement of 'Consistency' refers to the need for the IT system to maintain a uniform and coherent approach to its operations, data, and interfaces. This consistency should be maintained across all components of the system, including hardware, software, and network infrastructure. Consistency is essential for ensuring that the system operates smoothly and efficiently, without any unexpected or unpredictable behavior. It also helps to ensure that users can easily navigate and interact with the system, without encountering any confusing or conflicting information. To achieve consistency, the IT system should adhere to established standards and best practices, such as those defined by industry bodies or regulatory agencies. It should also use a common set of data definitions and formats, and ensure that all interfaces and interactions are designed and implemented in a consistent manner. In addition, the IT system should be designed and tested to ensure that it can maintain consistency even under varying conditions, such as changes in workload, network traffic, or hardware failures. This may involve implementing redundancy or failover mechanisms, or using load balancing techniques to distribute workload across multiple servers. Overall, the non-functional requirement of 'Consistency' is critical for ensuring that the IT system operates reliably and predictably, and provides a consistent and seamless experience for users. Example: One example of the IT non-functional requirement 'Consistency' could be ensuring that all user interfaces across a software application have a consistent look and feel, including font sizes, colors, and button placements. This can help to improve user experience and reduce confusion or frustration when navigating the application. LOST view: Digital Solution Non-Functional Requirements Catalogue view Identifier: http://data.europa.eu/dr8/egovera/ConsistencyRequirement EIRA traceability: eira:DigitalSolutionNonFunctionalRequirementRequirement ABB name: egovera:ConsistencyRequirement EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-05-16 dct:identifier: http://data.europa.eu/dr8/egovera/ConsistencyRequirement dct:title: Consistency Non-Functional Requirement Definition: Traffic pattern is an IT non-functional requirement that refers to the expected volume and frequency of user traffic on a system or application. It includes factors such as peak usage times, the number of concurrent users, and the expected growth rate of traffic over time. The traffic pattern requirement is critical in ensuring that the system can handle the expected load without experiencing performance issues such as slow response times or crashes. It also helps in determining the appropriate infrastructure and resources needed to support the system. Source: TOGAF Source reference: https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap03.html Additional information: According to the TOGAF specification, the non-functional requirement 'Traffic pattern' refers to the expected behavior of the system under different levels of traffic. This requirement is concerned with the system's ability to handle varying levels of user activity, data volume, and transaction processing. The Traffic pattern non-functional requirement is important for ensuring that the system can perform optimally under different traffic conditions. This requirement should be defined in terms of the expected traffic patterns, such as peak usage times, expected user activity levels, and the expected volume of data transactions. To meet this requirement, the system should be designed to handle the expected traffic patterns efficiently. This may involve the use of load balancing techniques, caching mechanisms, and other performance optimization strategies. The system should also be able to scale up or down as needed to accommodate changes in traffic patterns. In addition, the Traffic pattern non-functional requirement should be tested to ensure that the system can perform as expected under different traffic conditions. This may involve load testing, stress testing, and other performance testing techniques to simulate different traffic scenarios and measure the system's response. Overall, the Traffic pattern non-functional requirement is critical for ensuring that the system can handle varying levels of traffic and perform optimally under different usage scenarios. Example: One example of an IT non-functional requirement for 'Traffic pattern' could be for a website or application that needs to handle a high volume of traffic during peak hours, such as during a major sale event or a product launch. The requirement could specify that the system must be able to handle a certain number of concurrent users without experiencing any significant slowdowns or crashes. Additionally, it may require that the system be able to scale up or down as needed to accommodate fluctuations in traffic patterns. LOST view: Digital Solution Non-Functional Requirements Catalogue view Identifier: http://data.europa.eu/dr8/egovera/TrafficPatternRequirement EIRA traceability: eira:DigitalSolutionNonFunctionalRequirementRequirement ABB name: egovera:TrafficPatternRequirement EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-05-16 dct:identifier: http://data.europa.eu/dr8/egovera/TrafficpatternRequirement dct:title: Traffic pattern Non-Functional Requirement Definition: Privacy is an important non-functional requirement in IT systems that ensures the protection of sensitive information from unauthorized access, use, or disclosure. It involves implementing security measures such as encryption, access controls, and data masking to safeguard personal and confidential data. Privacy also includes compliance with legal and regulatory requirements such as GDPR, HIPAA, and CCPA. Maintaining privacy in IT systems is crucial for building trust with users and protecting their personal information from potential threats. Source: TOGAF Source reference: https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap03.html Additional information: According to the TOGAF specification, guidelines, and documentation, the non-functional requirement of 'Privacy' refers to the ability of a system to protect the confidentiality, integrity, and availability of personal information. This requirement is essential for ensuring that sensitive data is not disclosed to unauthorized parties, and that individuals have control over how their personal information is collected, used, and shared. To meet the Privacy requirement, the system must comply with relevant laws, regulations, and industry standards related to data protection and privacy. This includes implementing appropriate security measures such as encryption, access controls, and data masking to prevent unauthorized access, modification, or disclosure of personal information. The system must also provide users with clear and concise privacy policies that explain how their personal information is collected, used, and shared. Users must be given the option to opt-out of data collection or sharing, and their consent must be obtained before any personal information is collected or used. In addition, the system must have mechanisms in place to detect and respond to privacy breaches. This includes monitoring for unauthorized access or use of personal information, and taking appropriate action to mitigate any potential harm to affected individuals. Overall, the Privacy non-functional requirement is critical for ensuring that personal information is protected and that individuals have control over their data. By meeting this requirement, the system can build trust with users and stakeholders, and avoid potential legal or reputational risks associated with privacy breaches. Example: One example of the IT non-functional requirement 'Privacy' could be that the system must ensure that all user data is encrypted and stored securely to prevent unauthorized access or data breaches. LOST view: Digital Solution Non-Functional Requirements Catalogue view Identifier: http://data.europa.eu/dr8/egovera/PrivacyRequirement EIRA traceability: eira:DigitalSolutionNonFunctionalRequirementRequirement ABB name: egovera:PrivacyRequirement EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-05-16 dct:identifier: http://data.europa.eu/dr8/egovera/PrivacyRequirement dct:title: Privacy Non-Functional Requirement Definition: Logging is an IT non-functional requirement that involves the recording of events and activities within a system or application. This includes capturing information such as user actions, system errors, and performance metrics. The purpose of logging is to provide a detailed record of system behavior that can be used for troubleshooting, auditing, and analysis. Logging is essential for ensuring the security and reliability of IT systems, as it enables administrators to identify and address issues quickly and effectively. Additionally, logging can help organizations meet regulatory compliance requirements by providing a comprehensive record of system activity. Source: TOGAF Source reference: https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap03.html Additional information: According to the TOGAF specification, guidelines, and documentation, the non-functional requirement of 'Logging' refers to the ability of a system to record and store information about its activities and events in a structured and organized manner. This information can be used for various purposes, such as troubleshooting, auditing, compliance, and performance analysis. The logging requirement should specify the types of events that need to be logged, the format and structure of the log data, the storage location and retention period, and the access control and security measures for the log files. The logging mechanism should be reliable, efficient, and scalable, and should not impact the performance or availability of the system. The logging requirement should also consider the legal and regulatory requirements for data privacy, protection, and disclosure. The log data should be encrypted, anonymized, or masked if necessary, and should only be accessible to authorized personnel with a legitimate need to know. The logging requirement should be documented in the system architecture and design, and should be tested and validated during the system development and deployment phases. The logging mechanism should be monitored and maintained throughout the system lifecycle, and should be updated or improved as needed to meet changing business and technical requirements. Example: One example of the IT non-functional requirement 'Logging' could be for a financial application to log all user activity and transactions for auditing and compliance purposes. This would include logging user login and logout times, as well as any changes made to account balances or transactions. The logs would need to be secure and tamper-proof, with access restricted to authorized personnel only. The system would also need to be able to generate reports based on the logged data, such as transaction histories or user activity summaries. LOST view: Digital Solution Non-Functional Requirements Catalogue view Identifier: http://data.europa.eu/dr8/egovera/LoggingRequirement EIRA traceability: eira:DigitalSolutionNonFunctionalRequirementRequirement ABB name: egovera:LoggingRequirement EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-05-16 dct:identifier: http://data.europa.eu/dr8/egovera/LoggingRequirement dct:title: Logging Non-Functional Requirement Definition: EIRA Architecture Building Block ABB is a Requirement acting as a requirement of an intermediate level of granularity, in alignment with at least one EIF principle, formulated as an agreed normative statement in functional terms on a legal, organisational, semantic, or technical attribute of a To-Be European Public Service. An EIRA ABB might encapsulate several interoperability aspects Source: Europa Source reference: (https://ec.europa.eu/digital-building-blocks/wikis/display/CEFDIGITAL/What+is+a+Building+Block) Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): A Legal Act is an EIRA Architecture Building Block from a Legal view perspective. Identifier: http://data.europa.eu/dr8/EIRAArchitectureBuildingBlockRequirement eira:ID: ABB607 ABB name: eira:EIRAArchitectureBuildingBlockRequirement Last modification: 2022-23-01 Definition: Resiliency is an IT non-functional requirement that refers to the ability of a system to recover quickly and efficiently from unexpected events or failures. This includes the ability to maintain availability, performance, and data integrity in the face of disruptions such as hardware failures, network outages, or cyber attacks. A resilient system is designed to minimize downtime, prevent data loss, and ensure business continuity, even in the face of adverse conditions. This requirement is critical for any system that needs to operate reliably and consistently, particularly in mission-critical applications such as financial services, healthcare, or emergency response. Source: TOGAF Source reference: https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap03.html Additional information: According to the TOGAF specification, Resiliency is a non-functional requirement that refers to the ability of an IT system to recover from failures or disruptions and continue to function as intended. This requirement is essential for ensuring that the system can withstand unexpected events such as hardware failures, power outages, or cyber-attacks. To meet the Resiliency requirement, IT systems must be designed with redundancy and fault-tolerant mechanisms that enable them to continue operating even when one or more components fail. This may involve the use of backup systems, redundant hardware, or failover mechanisms that automatically switch to a backup system when the primary system fails. In addition to technical measures, Resiliency also requires the implementation of robust disaster recovery and business continuity plans that outline procedures for responding to disruptions and restoring normal operations as quickly as possible. These plans should be regularly tested and updated to ensure that they remain effective in the face of changing threats and circumstances. Overall, Resiliency is a critical non-functional requirement for IT systems that must be carefully considered and addressed throughout the entire system development lifecycle. By ensuring that systems are designed with Resiliency in mind, organizations can minimize the risk of downtime and data loss, and maintain the continuity of their operations even in the face of unexpected events. Example: One example of the IT non-functional requirement 'Resiliency' could be that the system should be able to recover from hardware or software failures within a specified time frame, without losing any data or causing significant downtime. This could involve implementing redundancy measures such as backup servers, failover mechanisms, and data replication to ensure that the system can continue to operate even in the event of a failure. Additionally, the system should be able to handle high levels of traffic or usage without becoming overwhelmed or crashing, and should be able to scale up or down as needed to accommodate changing demands. LOST view: Digital Solution Non-Functional Requirements Catalogue view Identifier: http://data.europa.eu/dr8/egovera/ResiliencyRequirement EIRA traceability: eira:DigitalSolutionNonFunctionalRequirementRequirement ABB name: egovera:ResiliencyRequirement EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-05-16 dct:identifier: http://data.europa.eu/dr8/egovera/ResiliencyRequirement dct:title: Resiliency Non-Functional Requirement Definition: An API contract is a non-functional requirement that specifies the rules and guidelines for how an application programming interface (API) should behave. It defines the expected behavior of the API, including the input and output formats, error handling, security, and performance. The API contract ensures that the API is consistent and predictable, making it easier for developers to use and integrate with other systems. It also helps to ensure that the API is reliable, scalable, and maintainable over time. Source: TOGAF Source reference: https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap03.html Additional information: According to the TOGAF specification, an API contract is a non-functional requirement that defines the terms and conditions for using an application programming interface (API). It specifies the rules and guidelines that must be followed by both the API provider and the API consumer to ensure that the API functions as intended and meets the required quality attributes. The API contract includes details such as the API's input and output parameters, error handling procedures, security requirements, performance expectations, and other technical specifications. It also outlines the expected behavior of the API under different scenarios and usage patterns. The API contract is a critical component of the API design process, as it helps to ensure that the API is reliable, scalable, and maintainable. It also helps to minimize the risk of errors and inconsistencies in the API implementation, which can lead to security vulnerabilities, performance issues, and other problems. To create an effective API contract, it is important to involve all stakeholders, including the API provider, API consumer, and any other relevant parties. The contract should be clear, concise, and easy to understand, and should be regularly reviewed and updated as needed to reflect changes in the API or its usage patterns. Example: One example of an IT non-functional requirement for an API contract could be that the API must have a clearly defined and documented interface that specifies the expected inputs, outputs, and behavior of the API. This interface should be consistent and stable over time, so that clients can rely on it and build their own applications around it. Additionally, the API should be designed to be scalable and performant, so that it can handle large volumes of requests and respond quickly to user actions. Finally, the API should be secure and protected against unauthorized access, with appropriate authentication and authorization mechanisms in place to ensure that only authorized users can access the API and its data. LOST view: Digital Solution Non-Functional Requirements Catalogue view Identifier: http://data.europa.eu/dr8/egovera/APIContractRequirement EIRA traceability: eira:DigitalSolutionNonFunctionalRequirementRequirement ABB name: egovera:APIContractRequirement EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-05-16 dct:identifier: http://data.europa.eu/dr8/egovera/APIcontractRequirement dct:title: API contract Non-Functional Requirement Definition: National Legal Act ABB is a Requirement enabling the adoption of laws on a national level. Source: Eur-Lex Source reference: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=LEGISSUM:ai0032 Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/NationalLegalActRequirement LOST view: Legal view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:NationalLegalActRequirement Example: he following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Real Decreto 4/2010, de 8 de enero, por el que se regula el Esquema Nacional de Interoperabilidad en el ámbito de la Administración Electrónica. https://www.boe.es/eli/es/rd/2010/01/08/4. The example provider is a National Regulation from Spanish National Government regulating the Interoperability Scheme. Interoperability Saliency: National Legal Act ABB is salient for legal interoperability because it helps to achieve different EU member states legal and juridical certainty in the exchange of information for public services. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/NationalLegalActRequirement EIF Layer: Legal Definition: Extensibility is an IT non-functional requirement that refers to the ability of a system to easily accommodate future changes or additions without requiring significant modifications to the existing system. This means that the system should be designed in a way that allows for new features, functionalities, and technologies to be added seamlessly, without disrupting the existing system's performance or stability. Extensibility is important for ensuring that the system remains relevant and adaptable to changing business needs and technological advancements. It also helps to reduce the cost and effort required for future upgrades and maintenance. Source: TOGAF Source reference: https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap03.html Additional information: According to the TOGAF specification, Extensibility is a non-functional requirement that refers to the ability of a system or application to be easily extended or modified without affecting its existing functionality. This requirement is important for organizations that need to adapt to changing business requirements or technological advancements. The Extensibility requirement can be achieved through the use of modular and scalable architectures that allow for the addition of new components or features. This can be achieved through the use of open standards, APIs, and other integration mechanisms that enable the integration of new functionality into the existing system. To ensure that the Extensibility requirement is met, it is important to establish clear guidelines and standards for the development and integration of new components. This includes defining the interfaces and protocols that will be used for communication between different components, as well as establishing testing and validation procedures to ensure that new components are compatible with the existing system. In addition, it is important to consider the impact of extensibility on system performance and scalability. This may require the use of distributed architectures, load balancing mechanisms, and other techniques to ensure that the system can handle the increased load and complexity that comes with the addition of new components. Overall, the Extensibility requirement is an important consideration for organizations that need to adapt to changing business requirements and technological advancements. By following the TOGAF guidelines and documentation, organizations can ensure that their systems are designed to be easily extended and modified, while maintaining their existing functionality and performance. Example: An example of the IT non-functional requirement 'Extensibility' could be that the software system should be designed in such a way that it can easily accommodate new features and functionalities in the future without requiring significant changes to the existing codebase. This means that the system should be modular, with clear separation of concerns and well-defined interfaces between different components, so that new modules can be added or existing ones can be modified without affecting the rest of the system. Additionally, the system should be designed with scalability in mind, so that it can handle increased load and data volumes as the user base grows. LOST view: Digital Solution Non-Functional Requirements Catalogue view Identifier: http://data.europa.eu/dr8/egovera/ExtensibilityRequirement EIRA traceability: eira:DigitalSolutionNonFunctionalRequirementRequirement ABB name: egovera:ExtensibilityRequirement EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-05-16 dct:identifier: http://data.europa.eu/dr8/egovera/ExtensibilityRequirement dct:title: Extensibility Non-Functional Requirement Definition: A [Digital Solution Requirement] ABB refers to a specific need or condition that must be met or satisfied by a digital system or product to achieve its intended purpose effectively Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/DigitalSolutionRequirementRequirement LOST view: Legal view EIRA concept: eira:ArchitectureBuildingBlock Interoperability Dimension: Structural IoP Viewpoint: EIRA Ontology viewpoint ABB name: eira:DigitalSolutionRequirementRequirement Additional identifier: http://data.europa.eu/dr8/DigitalSolutionRequirementRequirement EIF Layer: N/A Definition: Auditability is an IT non-functional requirement that refers to the ability of a system to provide a complete and accurate record of all activities and transactions that occur within it. This includes the ability to track changes made to data, monitor user access and permissions, and generate reports that can be used for compliance, regulatory, or legal purposes. The audit trail should be secure, tamper-proof, and easily accessible to authorized personnel. The purpose of auditability is to ensure accountability, transparency, and integrity of the system's operations. Source: TOGAF Source reference: https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap03.html Additional information: According to the TOGAF specification, Auditability is a non-functional requirement that refers to the ability of a system to provide a complete and accurate record of all transactions and activities that occur within the system. This includes the ability to track and record all user actions, system events, and data changes, as well as the ability to generate reports and alerts based on this information. The Auditability requirement is important for ensuring the integrity and security of a system, as well as for compliance with regulatory and legal requirements. It also helps to identify and investigate any potential security breaches or fraudulent activities. To meet the Auditability requirement, a system must have the following capabilities: 1. Logging and tracking: The system must be able to log and track all user actions, system events, and data changes, including the date, time, and user responsible for each action. 2. Reporting and analysis: The system must be able to generate reports and alerts based on the logged information, allowing administrators to identify and investigate any suspicious activity. 3. Security and access control: The system must have robust security and access control mechanisms in place to prevent unauthorized access to the audit logs and to ensure the integrity of the logged information. 4. Retention and archiving: The system must be able to retain and archive audit logs for a specified period of time, in accordance with regulatory and legal requirements. Overall, the Auditability requirement is an essential aspect of any system design, ensuring that the system is secure, compliant, and transparent in its operations. Example: One example of the IT non-functional requirement 'Auditability' could be for a financial management system to track and record all changes made to financial data, including who made the change, when it was made, and what the previous and new values were. This would allow for auditing and compliance purposes, as well as ensuring the accuracy and integrity of financial data. LOST view: Digital Solution Non-Functional Requirements Catalogue view Identifier: http://data.europa.eu/dr8/egovera/AuditabilityRequirement EIRA traceability: eira:DigitalSolutionNonFunctionalRequirementRequirement ABB name: egovera:AuditabilityRequirement EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-05-16 dct:identifier: http://data.europa.eu/dr8/egovera/AuditabilityRequirement dct:title: Auditability Non-Functional Requirement Definition: Replication is an IT non-functional requirement that refers to the ability of a system to duplicate or copy data or processes across multiple servers or locations. This is important for ensuring high availability and reliability of the system, as well as for disaster recovery purposes. Replication can be achieved through various techniques such as database replication, file replication, or server replication. The system should be able to handle replication in a seamless and efficient manner, without compromising performance or security. Source: TOGAF Source reference: https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap03.html Additional information: According to the TOGAF specification, Replication is a non-functional requirement that refers to the ability of a system to duplicate or copy data, processes, or services across multiple locations or instances. This requirement is important for ensuring high availability, fault tolerance, and disaster recovery capabilities. The Replication requirement can be further broken down into several sub-requirements, including: 1. Data Replication: This refers to the ability of a system to replicate data across multiple locations or instances. This can be achieved through various techniques such as database replication, file replication, or object replication. 2. Process Replication: This refers to the ability of a system to replicate processes or services across multiple locations or instances. This can be achieved through techniques such as load balancing, clustering, or virtualization. 3. Synchronization: This refers to the ability of a system to ensure that replicated data, processes, or services are kept in sync across all instances. This can be achieved through techniques such as data synchronization, process synchronization, or service synchronization. 4. Performance: This refers to the ability of a system to maintain performance levels even when replicating data, processes, or services across multiple locations or instances. This can be achieved through techniques such as caching, compression, or optimization. Overall, the Replication requirement is critical for ensuring that a system can provide high availability, fault tolerance, and disaster recovery capabilities. It is important to carefully consider the specific sub-requirements and techniques that will be used to achieve this requirement in order to ensure that the system is able to meet its performance and reliability goals. Example: One example of the IT non-functional requirement 'Replication' is in a database system where data needs to be replicated across multiple servers for redundancy and fault tolerance. This ensures that if one server fails, the data can still be accessed from another server without any disruption to the system. The replication process should be seamless and transparent to the end-users, ensuring that they can access the data without any delay or interruption. Additionally, the replication process should be efficient and scalable, allowing for easy addition of new servers as the system grows. LOST view: Digital Solution Non-Functional Requirements Catalogue view Identifier: http://data.europa.eu/dr8/egovera/ReplicationRequirement EIRA traceability: eira:DigitalSolutionNonFunctionalRequirementRequirement ABB name: egovera:ReplicationRequirement EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-05-16 dct:identifier: http://data.europa.eu/dr8/egovera/ReplicationRequirement dct:title: Replication Non-Functional Requirement Definition: Integrity is an IT non-functional requirement that ensures the accuracy, consistency, and reliability of data throughout its lifecycle. It involves maintaining the correctness and completeness of data, preventing unauthorized access or modification, and ensuring that data is not lost or corrupted due to system failures or errors. Integrity is critical for ensuring the trustworthiness of data and maintaining the credibility of the system that uses it. It is often achieved through the use of data validation, error checking, access controls, and backup and recovery mechanisms. Source: TOGAF Source reference: https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap03.html Additional information: According to the TOGAF specification, Integrity is a non-functional requirement that refers to the accuracy, consistency, and reliability of data and information within a system. It ensures that the data is protected from unauthorized access, modification, or deletion, and that it remains consistent and reliable throughout its lifecycle. Integrity is an essential requirement for any system that deals with sensitive or critical data, such as financial transactions, personal information, or medical records. It ensures that the data is not compromised or corrupted, and that it can be trusted by the users and stakeholders. To achieve integrity, the system must have appropriate security measures in place, such as access controls, authentication, encryption, and auditing. It must also have mechanisms to detect and prevent data tampering, such as checksums, digital signatures, or version control. Integrity is closely related to other non-functional requirements, such as availability, reliability, and performance. A system that lacks integrity may also suffer from data loss, downtime, or poor performance, which can have severe consequences for the users and the organization. Overall, integrity is a critical non-functional requirement that ensures the trustworthiness and reliability of data and information within a system. It must be carefully considered and implemented to ensure the security and effectiveness of the system. Example: One example of the IT non-functional requirement 'Integrity' is ensuring that data is not altered or modified during transmission or storage. This can be achieved through the use of encryption, checksums, and other security measures to prevent unauthorized access or tampering. Additionally, data backups and disaster recovery plans can help ensure that data remains intact and accessible in the event of a system failure or other disruption. LOST view: Digital Solution Non-Functional Requirements Catalogue view Identifier: http://data.europa.eu/dr8/egovera/IntegrityRequirement EIRA traceability: eira:DigitalSolutionNonFunctionalRequirementRequirement ABB name: egovera:IntegrityRequirement EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-05-16 dct:identifier: http://data.europa.eu/dr8/egovera/IntegrityRequirement dct:title: Integrity Non-Functional Requirement Definition: Disaster recovery is an IT non-functional requirement that ensures that a system can recover from any catastrophic event or disaster, such as natural disasters, power outages, or cyber-attacks. This requirement involves creating a plan and implementing strategies to minimize the impact of such events on the system's functionality and data. The disaster recovery plan should include backup and recovery procedures, redundant systems, and failover mechanisms to ensure that the system can quickly and efficiently recover from any disaster. The goal of disaster recovery is to minimize downtime, data loss, and ensure business continuity. Source: TOGAF Source reference: https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap03.html Additional information: According to the TOGAF specification, Disaster Recovery is a non-functional requirement that refers to the ability of an IT system to recover from a catastrophic event or disaster. This requirement is essential for ensuring the continuity of business operations and minimizing the impact of disruptions on the organization. The Disaster Recovery requirement includes the following elements: 1. Recovery Time Objective (RTO): This refers to the maximum amount of time that the IT system can be down before it must be restored to full functionality. The RTO is typically measured in hours or days and is determined by the criticality of the system to the business. 2. Recovery Point Objective (RPO): This refers to the maximum amount of data loss that the organization can tolerate in the event of a disaster. The RPO is typically measured in minutes or hours and is determined by the criticality of the data to the business. 3. Backup and Recovery Procedures: This refers to the processes and procedures that are in place to backup and restore the IT system in the event of a disaster. These procedures must be tested regularly to ensure that they are effective and can be executed quickly and efficiently. 4. Disaster Recovery Plan: This refers to the overall plan that outlines the steps that must be taken to recover the IT system in the event of a disaster. The plan must be comprehensive and include all necessary information, such as contact information for key personnel, backup and recovery procedures, and communication protocols. 5. Testing and Maintenance: This refers to the ongoing testing and maintenance of the Disaster Recovery plan and procedures to ensure that they remain effective and up-to-date. Testing must be conducted regularly to identify any weaknesses or gaps in the plan and to ensure that all personnel are familiar with their roles and responsibilities. Overall, the Disaster Recovery requirement is critical for ensuring the continuity of business operations in the event of a catastrophic event or disaster. Organizations must ensure that they have a comprehensive plan in place that includes backup and recovery procedures, testing and maintenance, and clear communication protocols to minimize the impact of disruptions on the organization. Example: In the event of a natural disaster or system failure, the system must be able to recover all data and functionality within 24 hours with minimal data loss. LOST view: Digital Solution Non-Functional Requirements Catalogue view Identifier: http://data.europa.eu/dr8/egovera/DisasterRecoveryRequirement EIRA traceability: eira:DigitalSolutionNonFunctionalRequirementRequirement ABB name: egovera:DisasterRecoveryRequirement EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-05-16 dct:identifier: http://data.europa.eu/dr8/egovera/DisasterrecoveryRequirement dct:title: Disaster recovery Non-Functional Requirement Definition: Modularity and reusability are non-functional requirements that refer to the ability of a software system to be broken down into smaller, independent components that can be easily reused in other parts of the system or in other systems altogether. This requirement is important because it allows for greater flexibility and scalability in software development, as well as reducing the amount of time and effort required to develop new software applications. By designing software with modularity and reusability in mind, developers can create more efficient and effective systems that are easier to maintain and update over time. Source: TOGAF Source reference: https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap03.html Additional information: Modularity and reusability are non-functional requirements that are essential for the development of robust and scalable IT systems. According to the TOGAF specification, guidelines, and documentation, modularity refers to the ability of a system to be broken down into smaller, independent components or modules. These modules can be developed, tested, and maintained separately, which makes it easier to modify or replace them without affecting the rest of the system. Reusability, on the other hand, refers to the ability of a system or its components to be used in different contexts or applications. This means that the system or its components should be designed in a way that they can be easily adapted or extended to meet the requirements of different users or applications. To achieve modularity and reusability, the TOGAF framework recommends the use of standard interfaces and protocols that allow different components to communicate with each other. This can be achieved through the use of service-oriented architecture (SOA) or microservices, which provide a modular and flexible approach to system design. In addition, the TOGAF framework recommends the use of design patterns and best practices that promote modularity and reusability. These include the use of abstraction, encapsulation, and inheritance to create modular and reusable components that can be easily extended or modified. Overall, modularity and reusability are critical non-functional requirements that should be considered throughout the entire system development lifecycle. By following the TOGAF framework and best practices, IT systems can be designed to be more flexible, scalable, and adaptable to changing business needs. Example: One example of the IT non-functional requirement 'Modularity and reusability' could be the development of a software application that can be easily integrated with other systems and components. This means that the application should be designed in a modular way, with clear interfaces and well-defined APIs, so that it can be easily reused and adapted to different environments and use cases. Additionally, the application should be built using standard technologies and programming languages, so that it can be easily maintained and updated over time. This requirement is important for organizations that need to integrate multiple systems and applications, as it helps to reduce development time and costs, and improves overall system performance and reliability. LOST view: Digital Solution Non-Functional Requirements Catalogue view Identifier: http://data.europa.eu/dr8/egovera/ModularityAndReusabilityRequirement EIRA traceability: eira:DigitalSolutionNonFunctionalRequirementRequirement ABB name: egovera:ModularityAndReusabilityRequirement EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-05-16 dct:identifier: http://data.europa.eu/dr8/egovera/ModularityandreusabilityRequirement dct:title: Modularity and reusability Non-Functional Requirement Definition: Configurability is an IT non-functional requirement that refers to the ability of a system or software to be easily customized or modified to meet the specific needs or preferences of different users or organizations. This includes the ability to change settings, parameters, and other aspects of the system without requiring extensive programming or technical knowledge. Configurability is important for ensuring that the system can adapt to changing requirements and environments, and can be tailored to meet the unique needs of different users or organizations. Source: TOGAF Source reference: https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap03.html Additional information: According to the TOGAF specification, configurability is a non-functional requirement that refers to the ability of a system or application to be easily configured or customized to meet the specific needs of different users or organizations. This includes the ability to modify settings, parameters, and other configuration options without requiring significant changes to the underlying code or architecture of the system. Configurability is an important non-functional requirement for many systems, particularly those that are used by multiple organizations or users with different requirements. By providing a high degree of configurability, these systems can be adapted to meet the specific needs of each user or organization, without requiring significant customization or development efforts. To meet the configurability requirement, systems should provide a range of configuration options that are easy to access and modify. These options should be well-documented and clearly explained, so that users can understand how to make the necessary changes. Additionally, systems should be designed in a modular and flexible way, so that changes to one part of the system do not require significant changes to other parts. Overall, configurability is an important non-functional requirement that can help to ensure that systems are adaptable and flexible enough to meet the needs of different users and organizations. By following the TOGAF guidelines and best practices for configurability, organizations can ensure that their systems are well-designed and easy to use, while also providing the necessary flexibility and customization options to meet the needs of their users. Example: One example of the IT non-functional requirement 'Configurability' could be the ability for a software application to be easily customized and adapted to meet the specific needs and requirements of different users or organizations. This could include features such as the ability to modify user interface elements, configure system settings and preferences, and integrate with other software systems or platforms. By providing a high degree of configurability, the application can be more easily tailored to meet the unique needs of different users, improving overall usability and user satisfaction. LOST view: Digital Solution Non-Functional Requirements Catalogue view Identifier: http://data.europa.eu/dr8/egovera/ConfigurabilityRequirement EIRA traceability: eira:DigitalSolutionNonFunctionalRequirementRequirement ABB name: egovera:ConfigurabilityRequirement EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-05-16 dct:identifier: http://data.europa.eu/dr8/egovera/ConfigurabilityRequirement dct:title: Configurability Non-Functional Requirement Definition: Elasticity is an IT non-functional requirement that refers to the ability of a system to scale up or down in response to changes in demand. This means that the system should be able to handle increased traffic or workload without compromising its performance or stability. Elasticity is important for systems that experience unpredictable or fluctuating demand, as it allows them to maintain optimal performance and avoid downtime. It also helps organizations to optimize their resource utilization and reduce costs by scaling down when demand decreases. Source: TOGAF Source reference: https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap03.html Additional information: According to the TOGAF specification, Elasticity is a non-functional requirement that refers to the ability of a system to scale up or down its resources in response to changing demands. This requirement is closely related to the concept of scalability, which refers to the ability of a system to handle increasing workloads without compromising its performance. Elasticity is an important requirement for systems that are expected to handle varying levels of traffic or workload. For example, a web application that experiences a sudden surge in traffic due to a marketing campaign or a news event should be able to scale up its resources to handle the increased demand. Similarly, a system that experiences a decrease in traffic during off-peak hours should be able to scale down its resources to save costs. To achieve elasticity, a system should be designed with the following characteristics: 1. Modularity: The system should be composed of independent modules that can be scaled up or down independently. 2. Automation: The scaling process should be automated to minimize human intervention and reduce the risk of errors. 3. Monitoring: The system should be monitored continuously to detect changes in demand and trigger the scaling process. 4. Resilience: The system should be able to handle failures and recover quickly from them. 5. Flexibility: The system should be able to adapt to different types of workloads and resource requirements. Overall, elasticity is an important non-functional requirement that can help ensure that a system is able to handle changing demands and provide a consistent level of performance. Example: An example of the IT non-functional requirement 'Elasticity' could be the ability of a cloud-based application to automatically scale up or down its computing resources based on the current demand. This means that the application should be able to handle sudden spikes in traffic without crashing or slowing down, while also being able to reduce its resource usage during periods of low activity to save costs. LOST view: Digital Solution Non-Functional Requirements Catalogue view Identifier: http://data.europa.eu/dr8/egovera/ElasticityRequirement EIRA traceability: eira:DigitalSolutionNonFunctionalRequirementRequirement ABB name: egovera:ElasticityRequirement EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-05-16 dct:identifier: http://data.europa.eu/dr8/egovera/ElasticityRequirement dct:title: Elasticity Non-Functional Requirement Definition: Alerts and monitoring are non-functional requirements that ensure that the system can detect and reporting any issues or anomalies that may arise during its operation. This includes the ability to monitor system performance, detect errors, and notify relevant stakeholders in real-time. The alerts and monitoring system should be designed to provide timely and accurate information to enable quick and effective decision-making, as well as to ensure that the system is always available and performing optimally. This requirement is critical for ensuring the reliability, availability, and performance of the system. Source: TOGAF Source reference: https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap03.html Additional information: According to the TOGAF specification, 'Alerts and monitoring' is a non-functional requirement that pertains to the system's ability to detect and report errors, failures, and other critical events. This requirement is essential for ensuring the system's reliability, availability, and performance. To meet this requirement, the system must be equipped with monitoring tools and mechanisms that can track and analyze various system metrics, such as CPU usage, memory utilization, network traffic, and disk space. These tools should be able to generate alerts and notifications when predefined thresholds are exceeded or when specific events occur. The alerts and notifications should be sent to the appropriate stakeholders, such as system administrators, support teams, or business users, depending on the severity and impact of the event. The alerts should provide sufficient information to enable the stakeholders to take appropriate actions, such as investigating the root cause of the problem, applying corrective measures, or escalating the issue to higher levels of management. The monitoring tools should also be able to generate reports and dashboards that provide insights into the system's performance and health. These reports should be customizable and configurable to meet the specific needs of different stakeholders. Overall, the 'Alerts and monitoring' non-functional requirement is critical for ensuring the system's reliability, availability, and performance. By providing real-time visibility into the system's health and performance, the monitoring tools enable stakeholders to proactively identify and resolve issues before they escalate into major problems. Example: One example of the IT non-functional requirement 'Alerts and monitoring' could be for a financial institution's online banking system to have real-time monitoring of all transactions and user activity, with alerts triggered for any suspicious or potentially fraudulent activity. This would help ensure the security and integrity of the system and protect both the institution and its customers from potential financial losses. LOST view: Digital Solution Non-Functional Requirements Catalogue view Identifier: http://data.europa.eu/dr8/egovera/AlertsAndMonitoringRequirement EIRA traceability: eira:DigitalSolutionNonFunctionalRequirementRequirement ABB name: egovera:AlertsAndMonitoringRequirement EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-05-16 dct:identifier: http://data.europa.eu/dr8/egovera/AlertsandmonitoringRequirement dct:title: Alerts and monitoring Non-Functional Requirement Definition: Geodes is a non-functional requirement that refers to the ability of a system to accurately determine the location of a user or device. This requirement is important for systems that rely on location-based services, such as navigation apps or emergency response systems. Geodes involves the use of GPS or other location tracking technologies to provide precise location data, which can be used to improve the functionality and usability of the system. The accuracy and reliability of geodes is critical, as errors or inaccuracies can lead to serious consequences in certain applications. Source: TOGAF Source reference: https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap03.html Additional information: According to the TOGAF specification, Geodes can be classified as a non-functional requirement related to the performance and scalability of the IT system. Geodes refer to the ability of the system to handle and process large volumes of data and transactions in a timely and efficient manner. This requirement is critical for systems that deal with geospatial data, such as mapping and navigation applications. To meet the Geodes requirement, the IT system must be designed to handle large amounts of data and transactions without compromising performance or scalability. This can be achieved through the use of distributed computing architectures, such as cloud computing or grid computing, which allow for the processing of data across multiple nodes or servers. Additionally, the IT system must be designed to optimize the use of resources, such as memory and processing power, to ensure that performance is not impacted by the volume of data being processed. This can be achieved through the use of caching mechanisms, data compression, and other optimization techniques. Overall, the Geodes requirement is critical for systems that deal with geospatial data and must be carefully considered during the design and implementation of the IT system to ensure that performance and scalability are not compromised. Example: One example of an IT non-functional requirement for geodes could be that the system must be able to accurately track and display the location of assets or vehicles in real-time, with a margin of error no greater than 10 meters. This requirement would ensure that the system is reliable and precise enough to be used for applications such as fleet management or logistics tracking. LOST view: Digital Solution Non-Functional Requirements Catalogue view Identifier: http://data.europa.eu/dr8/egovera/GeodesRequirement EIRA traceability: eira:DigitalSolutionNonFunctionalRequirementRequirement ABB name: egovera:GeodesRequirement EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-05-16 dct:identifier: http://data.europa.eu/dr8/egovera/GeodesRequirement dct:title: Geodes Non-Functional Requirement Definition: Pluggability is an IT non-functional requirement that refers to the ability of a system to easily integrate with other systems or components without requiring significant modifications to the existing codebase. This requirement ensures that the system can be easily extended or customized by adding or removing components, modules, or plugins, without affecting the overall functionality of the system. Pluggability is essential for systems that need to be scalable, flexible, and adaptable to changing business requirements, as it allows for easy integration with third-party tools and technologies. Source: TOGAF Source reference: https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap03.html Additional information: According to the TOGAF specification, Pluggability is a non-functional requirement that refers to the ability of a system or application to easily integrate with other systems or components without requiring significant modifications to the existing architecture. This requirement is closely related to the concept of interoperability, which is the ability of different systems to work together seamlessly. Pluggability is an important non-functional requirement for modern IT systems, as it allows organizations to easily integrate new technologies and components into their existing infrastructure. This can help to reduce costs, improve efficiency, and enhance the overall functionality of the system. To achieve pluggability, IT systems must be designed with a modular architecture that allows for easy integration of new components. This can be achieved through the use of standard interfaces, protocols, and APIs that enable different systems to communicate with each other. In addition, pluggability requires that IT systems be designed with a high degree of flexibility and scalability. This means that the system must be able to adapt to changing requirements and accommodate new components as they are added. Overall, pluggability is an important non-functional requirement for IT systems that enables organizations to easily integrate new technologies and components into their existing infrastructure. By designing systems with a modular architecture and a high degree of flexibility, organizations can achieve pluggability and reap the benefits of a more efficient and effective IT infrastructure. Example: One example of the IT non-functional requirement 'Pluggability' could be the ability of a software application to seamlessly integrate with third-party plugins or modules. For instance, a content management system (CMS) should be able to support various plugins for search engine optimization (SEO), social media integration, and e-commerce functionality. The pluggability requirement ensures that the software can be easily extended and customized to meet the specific needs of the users without requiring significant modifications to the core codebase. LOST view: Digital Solution Non-Functional Requirements Catalogue view Identifier: http://data.europa.eu/dr8/egovera/PluggabilityRequirement EIRA traceability: eira:DigitalSolutionNonFunctionalRequirementRequirement ABB name: egovera:PluggabilityRequirement EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-05-16 dct:identifier: http://data.europa.eu/dr8/egovera/PluggabilityRequirement dct:title: Pluggability Non-Functional Requirement Definition: Deployment stamps are a non-functional requirement that refers to the need for a system to have a timestamp or version number associated with each deployment. This allows for easy tracking and identification of different versions of the system, as well as the ability to roll back to a previous version if necessary. Deployment stamps are important for ensuring the stability and reliability of a system, as well as for facilitating efficient and effective maintenance and troubleshooting. Source: TOGAF Source reference: https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap03.html Additional information: According to the TOGAF specification, Deployment stamps are a non-functional requirement that pertains to the deployment of software applications. This requirement specifies that each deployment of the software application must be stamped with a unique identifier that indicates the version of the application that has been deployed. The purpose of this requirement is to ensure that the deployment process is traceable and auditable. By having a unique identifier for each deployment, it becomes easier to track changes and identify any issues that may arise during the deployment process. The deployment stamp should be generated automatically by the deployment tool or system and should be stored in a central repository. This repository should be accessible to authorized personnel who need to track the deployment process. In addition to the unique identifier, the deployment stamp should also include information such as the date and time of the deployment, the environment in which the application was deployed, and any other relevant information that may be useful for tracking and auditing purposes. Overall, the Deployment stamps non-functional requirement is an important aspect of ensuring that the deployment process is traceable and auditable, which is essential for maintaining the integrity and reliability of software applications. Example: Deployment stamps refer to the requirement that each version of the software being deployed must have a unique identifier or timestamp associated with it. This helps to ensure that the correct version of the software is being deployed and that any issues can be traced back to a specific version. For example, a banking application may require deployment stamps to ensure that the correct version of the software is being used to process financial transactions. LOST view: Digital Solution Non-Functional Requirements Catalogue view Identifier: http://data.europa.eu/dr8/egovera/DeploymentStampsRequirement EIRA traceability: eira:DigitalSolutionNonFunctionalRequirementRequirement ABB name: egovera:DeploymentStampsRequirement EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-05-16 dct:identifier: http://data.europa.eu/dr8/egovera/DeploymentstampsRequirement dct:title: Deployment stamps Non-Functional Requirement Definition: Observability is a non-functional requirement in IT that refers to the ability to monitor and analyze the behavior of a system or application in real-time. It involves collecting and analyzing data from various sources, such as logs, metrics, and traces, to gain insights into the system's performance, availability, and reliability. Observability helps IT teams identify and troubleshoot issues quickly, improve system performance, and ensure that the system meets the desired level of service. It is an essential requirement for complex and distributed systems that require constant monitoring and analysis to ensure optimal performance. Source: TOGAF Source reference: https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap03.html Additional information: Observability is a non-functional requirement that refers to the ability of a system to be monitored and analyzed in order to detect and diagnose issues. According to the TOGAF specification, observability is a key aspect of system performance and reliability, as it allows for proactive identification and resolution of problems before they impact users. To achieve observability, a system must be designed with the ability to collect and analyze data from various sources, including logs, metrics, and traces. This data must be made available to monitoring and analysis tools, which can then provide insights into system behavior and performance. The TOGAF guidelines recommend that observability be considered throughout the entire system development lifecycle, from initial design through to deployment and ongoing maintenance. This includes defining clear metrics and logging requirements, as well as selecting appropriate monitoring and analysis tools. In addition, the TOGAF documentation emphasizes the importance of ensuring that observability is integrated into the overall system architecture, rather than being treated as an afterthought. This requires careful consideration of factors such as data collection and storage, data processing and analysis, and user access to monitoring and analysis tools. Overall, observability is a critical non-functional requirement for any system that requires high levels of performance and reliability. By following the TOGAF guidelines and best practices, organizations can ensure that their systems are designed with observability in mind, and are able to proactively identify and resolve issues before they impact users. Example: One example of the IT non-functional requirement 'Observability' could be the ability to monitor and track system performance metrics such as CPU usage, memory usage, network traffic, and response times. This would allow IT teams to quickly identify and troubleshoot any issues that may arise, ensuring that the system remains reliable and available to users. Additionally, observability could also include the ability to log and analyze user behavior, allowing for insights into how the system is being used and how it can be improved. LOST view: Digital Solution Non-Functional Requirements Catalogue view Identifier: http://data.europa.eu/dr8/egovera/ObservabilityRequirement EIRA traceability: eira:DigitalSolutionNonFunctionalRequirementRequirement ABB name: egovera:ObservabilityRequirement EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-05-16 dct:identifier: http://data.europa.eu/dr8/egovera/ObservabilityRequirement dct:title: Observability Non-Functional Requirement Definition: Deployability is an IT non-functional requirement that refers to the ease and efficiency with which software applications can be deployed and installed on different platforms and environments. It involves ensuring that the software can be easily installed, configured, and updated without causing any disruption to the existing system. Deployability is critical for ensuring that software can be quickly and easily rolled out to users, reducing downtime, and minimizing the risk of errors or conflicts. It also helps to ensure that the software can be easily maintained and updated over time, ensuring that it remains secure and up to date with the latest features and functionality. Source: TOGAF Source reference: https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap03.html Additional information: According to the TOGAF specification, guidelines, and documentation, the non-functional requirement of Deployability refers to the ease with which a system or application can be deployed into a production environment. This requirement encompasses a range of factors, including the ease of installation, configuration, and maintenance of the system, as well as the ability to scale the system to meet changing demands. To meet the Deployability requirement, the system must be designed with a focus on ease of deployment. This can include the use of standard deployment tools and processes, such as automated deployment scripts and configuration management tools. The system must also be designed to be easily configurable, with clear documentation and support for common configuration scenarios. In addition, the system must be designed to be easily maintainable, with clear documentation and support for common maintenance tasks. This can include the use of automated monitoring and alerting tools, as well as the ability to easily diagnose and resolve issues. Finally, the system must be designed to be scalable, with the ability to easily add or remove resources as needed to meet changing demands. This can include the use of cloud-based infrastructure, as well as the ability to easily add or remove servers or other resources as needed. Overall, the Deployability requirement is critical to ensuring that a system or application can be easily and reliably deployed into a production environment, and that it can be easily maintained and scaled to meet changing demands. Example: One example of the IT non-functional requirement 'Deployability' could be the ability of a software application to be easily installed and configured on different operating systems and hardware configurations without requiring extensive technical knowledge or expertise. This could include features such as automated installation scripts, clear documentation and user guides, and compatibility with common deployment tools and platforms. The goal of this requirement is to ensure that the application can be quickly and efficiently deployed in a variety of environments, reducing the time and effort required for IT teams to set up and maintain the software. LOST view: Digital Solution Non-Functional Requirements Catalogue view Identifier: http://data.europa.eu/dr8/egovera/DeployabilityRequirement EIRA traceability: eira:DigitalSolutionNonFunctionalRequirementRequirement ABB name: egovera:DeployabilityRequirement EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-05-16 dct:identifier: http://data.europa.eu/dr8/egovera/DeployabilityRequirement dct:title: Deployability Non-Functional Requirement Definition: Accessibility is an IT non-functional requirement that ensures the system or application can be used by people with disabilities or impairments. This includes providing features such as screen readers, keyboard navigation, and alternative text for images. The goal of accessibility is to make sure that everyone, regardless of their abilities, can access and use the system or application. This requirement is important for compliance with accessibility laws and regulations, as well as for creating an inclusive and user-friendly experience for all users. Source: TOGAF Source reference: https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap03.html Additional information: According to the TOGAF specification, Accessibility is a non-functional requirement that refers to the ability of a system or application to be used by people with disabilities. This includes individuals with visual, auditory, physical, or cognitive impairments. Accessibility is an important consideration for any system or application, as it ensures that all users can access and use the system or application effectively. This requirement is particularly important for systems or applications that are used by the public, as they must comply with accessibility standards and guidelines set by regulatory bodies. To meet the Accessibility non-functional requirement, the system or application must be designed and developed with accessibility in mind. This includes providing alternative ways of accessing information, such as text-to-speech or screen readers for visually impaired users, and ensuring that the system or application is navigable using only a keyboard for users with physical impairments. The system or application must also comply with accessibility standards and guidelines, such as the Web Content Accessibility Guidelines (WCAG) and the Americans with Disabilities Act (ADA). Compliance with these standards and guidelines ensures that the system or application is accessible to all users, regardless of their abilities. In summary, the Accessibility non-functional requirement requires that the system or application be designed and developed with accessibility in mind, and comply with accessibility standards and guidelines to ensure that all users can access and use the system or application effectively. Example: One example of an IT non-functional requirement for accessibility could be that the website or application must be designed to be compatible with screen readers and other assistive technologies commonly used by people with disabilities. This could include ensuring that all images have alt text descriptions, using clear and concise language, and providing keyboard shortcuts for navigation. Additionally, the website or application should be designed with a high contrast color scheme and large, easy-to-read fonts to accommodate users with visual impairments. LOST view: Digital Solution Non-Functional Requirements Catalogue view Identifier: http://data.europa.eu/dr8/egovera/AccessibilityRequirement EIRA traceability: eira:DigitalSolutionNonFunctionalRequirementRequirement ABB name: egovera:AccessibilityRequirement EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-05-16 dct:identifier: http://data.europa.eu/dr8/egovera/AccessibilityRequirement dct:title: Accessibility Non-Functional Requirement Definition: Compliance is an IT non-functional requirement that refers to the ability of a system or application to adhere to legal, regulatory, and industry standards. This requirement ensures that the system or application meets the necessary security, privacy, and data protection standards, as well as any other relevant regulations. Compliance is critical for organizations that handle sensitive data, such as financial institutions, healthcare providers, and government agencies, as it helps to mitigate risks and avoid legal and financial penalties. Source: TOGAF Source reference: https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap03.html Additional information: According to the TOGAF specification, Compliance is a non-functional requirement that refers to the ability of an IT system to adhere to legal, regulatory, and industry standards. Compliance requirements are often imposed by external entities, such as government agencies or industry associations, and failure to comply can result in legal or financial penalties. To ensure compliance, IT systems must be designed and implemented in accordance with relevant standards and regulations. This may involve incorporating specific security measures, data protection protocols, or other controls to meet compliance requirements. Compliance is an important consideration for organizations in many industries, particularly those that handle sensitive data or operate in highly regulated environments. By ensuring compliance, organizations can minimize the risk of legal or financial penalties, protect their reputation, and demonstrate their commitment to ethical and responsible business practices. Overall, compliance is a critical non-functional requirement that must be carefully considered and addressed in the design and implementation of IT systems. Example: One example of an IT non-functional requirement for compliance could be ensuring that the system meets all relevant regulatory requirements, such as HIPAA for healthcare data or PCI DSS for credit card information. This could include implementing appropriate security measures, maintaining audit logs, and regularly conducting vulnerability assessments. LOST view: Digital Solution Non-Functional Requirements Catalogue view Identifier: http://data.europa.eu/dr8/egovera/ComplianceRequirement EIRA traceability: eira:DigitalSolutionNonFunctionalRequirementRequirement ABB name: egovera:ComplianceRequirement EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-05-16 dct:identifier: http://data.europa.eu/dr8/egovera/ComplianceRequirement dct:title: Compliance Non-Functional Requirement Definition: Security is a non-functional requirement that refers to the ability of a system to protect itself against unauthorized access, data breaches, and other malicious activities. It involves implementing measures such as encryption, access controls, firewalls, and intrusion detection systems to safeguard the system and its data. Security is essential for any system that handles sensitive information or performs critical functions, as a breach can result in significant financial, legal, and reputational damage. Therefore, security must be a top priority in the design, development, and deployment of any IT system. Source: TOGAF Source reference: https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap03.html Additional information: According to the TOGAF specification, guidelines, and documentation, the non-functional requirement of "Security" refers to the ability of a system to protect against unauthorized access, modification, or destruction of data. This requirement encompasses a range of security measures, including authentication, authorization, encryption, and auditing. To meet the Security requirement, a system must be designed to ensure that only authorized users can access sensitive data or perform certain actions. This may involve implementing strong passwords, multi-factor authentication, or other access control mechanisms. Additionally, the system must be able to detect and prevent unauthorized access attempts, such as through intrusion detection systems or firewalls. Another aspect of the Security requirement is data protection. This involves ensuring that data is encrypted both in transit and at rest, and that appropriate measures are in place to prevent data loss or corruption. The system must also be able to recover from security incidents, such as by restoring data from backups or rolling back transactions. Finally, the Security requirement includes auditing and monitoring capabilities. The system must be able to track user activity and generate audit logs, which can be used to investigate security incidents or comply with regulatory requirements. This may involve implementing logging and monitoring tools, as well as establishing policies and procedures for reviewing and analyzing audit data. Example: One example of an IT non-functional requirement for security could be that the system must have a secure login process that includes multi-factor authentication and password complexity requirements to prevent unauthorized access. LOST view: Digital Solution Non-Functional Requirements Catalogue view Identifier: http://data.europa.eu/dr8/egovera/SecurityRequirement EIRA traceability: eira:DigitalSolutionNonFunctionalRequirementRequirement ABB name: egovera:SecurityRequirement EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-05-16 dct:identifier: http://data.europa.eu/dr8/egovera/SecurityRequirement dct:title: Security Non-Functional Requirement Definition: Authorization is a non-functional requirement in IT that refers to the process of granting or denying access to specific resources or functionalities within a system. It involves verifying the identity of a user and determining their level of access based on their role or permissions. Authorization is essential for ensuring the security and integrity of a system, as it prevents unauthorized users from accessing sensitive information or performing actions that could compromise the system. It also helps to maintain accountability by tracking user activity and ensuring that actions are performed by authorized individuals. Source: TOGAF Source reference: https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap03.html Additional information: Authorization is a non-functional requirement that is related to the security aspect of an IT system. It refers to the process of granting or denying access to resources or functionalities based on the identity and privileges of the user or entity requesting access. According to the TOGAF specification, Authorization is a key aspect of security architecture and should be designed to ensure that only authorized users or entities can access the system or its resources. The authorization process should be based on a well-defined set of policies and rules that are consistent with the organization's security policies and regulatory requirements. The TOGAF guidelines recommend that the authorization process should be implemented using a combination of authentication, authorization, and access control mechanisms. Authentication is the process of verifying the identity of the user or entity requesting access, while authorization is the process of determining whether the user or entity has the necessary privileges to access the requested resource. Access control is the process of enforcing the authorization decisions by controlling the actual access to the resource. To ensure that the authorization process is effective, the TOGAF documentation recommends that the security architecture should include mechanisms for monitoring and auditing the authorization process. This will help to detect and prevent unauthorized access attempts and ensure that the system is compliant with the organization's security policies and regulatory requirements. In summary, Authorization is a non-functional requirement that is critical for ensuring the security of an IT system. It should be designed based on a well-defined set of policies and rules, and implemented using a combination of authentication, authorization, and access control mechanisms. The authorization process should be monitored and audited to ensure that it is effective and compliant with the organization's security policies and regulatory requirements. Example: One example of an IT non-functional requirement for Authorization could be that only users with specific roles or permissions are able to access certain features or data within a software application. This could include restrictions on who can create, edit, or delete certain types of content, or who can view sensitive information such as financial data or personal information. The authorization system should also be secure and reliable, ensuring that unauthorized users cannot gain access to restricted areas or data. LOST view: Digital Solution Non-Functional Requirements Catalogue view Identifier: http://data.europa.eu/dr8/egovera/AuthorizationRequirement EIRA traceability: eira:DigitalSolutionNonFunctionalRequirementRequirement ABB name: egovera:AuthorizationRequirement EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-05-16 dct:identifier: http://data.europa.eu/dr8/egovera/AuthorizationRequirement dct:title: Authorization Non-Functional Requirement Definition: Compatibility is an IT non-functional requirement that refers to the ability of a system or software to function properly with other systems, software, hardware, or environments. It ensures that the system can operate seamlessly with other systems, without any compatibility issues or conflicts. Compatibility is essential for ensuring that the system can integrate with other systems and can be used by a wide range of users, regardless of their hardware or software configurations. It also ensures that the system can be easily upgraded or migrated to newer versions without any compatibility issues. Source: TOGAF Source reference: https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap03.html Additional information: According to the TOGAF specification, Compatibility is an IT non-functional requirement that refers to the ability of a system or application to operate in conjunction with other systems or applications. This requirement ensures that the system or application can integrate seamlessly with other systems or applications without causing any disruption or compatibility issues. Compatibility can be achieved through adherence to industry standards, protocols, and interfaces. The system or application must be designed to work with different operating systems, hardware, and software configurations. It should also be able to communicate with other systems or applications using standard communication protocols. The compatibility requirement also includes backward compatibility, which ensures that the system or application can work with older versions of software or hardware. This is important to ensure that users can continue to use the system or application even if they have not upgraded their hardware or software. To ensure compatibility, it is important to conduct thorough testing and validation of the system or application. This includes testing for interoperability with other systems or applications, as well as testing for compatibility with different hardware and software configurations. Overall, the compatibility requirement is critical to ensure that the system or application can work seamlessly with other systems or applications, and that users can continue to use the system or application without any disruption or compatibility issues. Example: One example of the IT non-functional requirement 'Compatibility' could be ensuring that a software application is compatible with multiple operating systems such as Windows, Mac, and Linux. This would ensure that the application can be used by a wider range of users regardless of their preferred operating system. LOST view: Digital Solution Non-Functional Requirements Catalogue view Identifier: http://data.europa.eu/dr8/egovera/CompatibilityRequirement EIRA traceability: eira:DigitalSolutionNonFunctionalRequirementRequirement ABB name: egovera:CompatibilityRequirement EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-05-16 dct:identifier: http://data.europa.eu/dr8/egovera/CompatibilityRequirement dct:title: Compatibility Non-Functional Requirement Definition: Nonrepudiation is an IT non-functional requirement that ensures that the sender and the receiver cannot deny the sending or reception of a message. It is a security measure that provides proof of the authenticity and integrity of a message, ensuring that it cannot be altered or tampered with during transmission. Nonrepudiation is essential in situations where legal or financial transactions are involved, as it provides evidence that can be used to resolve disputes or prove compliance with regulations. Source: TOGAF Source reference: https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap03.html Additional information: Nonrepudiation is an IT non-functional requirement that ensures that the sender of a message cannot deny sending it and the receiver cannot deny receiving it. This requirement is essential in situations where there is a need to establish accountability and traceability of communication between parties. According to the TOGAF specification, nonrepudiation is a security requirement that is achieved through the use of digital signatures, timestamps, and other cryptographic techniques. These techniques ensure that messages are tamper-proof and that their origin and integrity can be verified. Nonrepudiation is an important requirement in many industries, including finance, healthcare, and legal services. It helps to prevent fraud, disputes, and other legal issues that may arise from disputes over the authenticity of messages. To ensure nonrepudiation, IT systems must be designed with security in mind. This includes implementing strong authentication and access controls, using encryption to protect data in transit and at rest, and monitoring systems for suspicious activity. Additionally, organizations must have policies and procedures in place to ensure that nonrepudiation requirements are met and that any violations are addressed promptly. Overall, nonrepudiation is a critical IT non-functional requirement that helps to ensure the integrity and accountability of communication between parties. By following the TOGAF guidelines and documentation, organizations can design and implement systems that meet this requirement and provide a secure and reliable platform for communication and collaboration. Example: Nonrepudiation is an IT non-functional requirement that ensures that a user cannot deny having performed a particular action or transaction. For example, in an online banking system, nonrepudiation ensures that a user cannot deny having made a particular transaction, such as transferring funds to another account. This is achieved through the use of digital signatures and other cryptographic techniques that provide evidence of the user's identity and the authenticity of the transaction. LOST view: Digital Solution Non-Functional Requirements Catalogue view Identifier: http://data.europa.eu/dr8/egovera/NonrepudiationRequirement EIRA traceability: eira:DigitalSolutionNonFunctionalRequirementRequirement ABB name: egovera:NonrepudiationRequirement EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-05-16 dct:identifier: http://data.europa.eu/dr8/egovera/NonrepudiationRequirement dct:title: Nonrepudiation Non-Functional Requirement Definition: Agility is an IT non-functional requirement that refers to the ability of a system to adapt quickly and easily to changing business needs or market conditions. It involves the system's ability to respond to new requirements, integrate with other systems, and scale up or down as needed. An agile system is one that can be easily modified or updated without disrupting the overall functionality of the system. This requirement is important for businesses that need to stay competitive and responsive to changing market conditions. Source: TOGAF Source reference: https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap03.html Additional information: According to the TOGAF specification, Agility is a non-functional requirement that refers to the ability of an IT system to respond quickly and effectively to changing business needs and market conditions. This requirement is closely related to the concept of flexibility, which involves the ability to adapt to new situations and requirements. To meet the Agility requirement, an IT system must be designed with a high degree of modularity, scalability, and interoperability. It should be able to integrate easily with other systems and technologies, and should be able to support a wide range of business processes and workflows. In addition, an Agile IT system should be designed with a focus on continuous improvement and innovation. This means that it should be able to evolve and adapt over time, incorporating new features and functionality as needed to meet changing business needs. To achieve these goals, an Agile IT system should be built using modern software development methodologies such as Agile or DevOps. It should also be designed with a high degree of automation, including automated testing, deployment, and monitoring. Overall, the Agility requirement is an important consideration for any IT system, as it can help to ensure that the system remains relevant and effective in the face of changing business needs and market conditions. By following the TOGAF guidelines and documentation, IT architects and designers can create systems that are both flexible and adaptable, and that can support the evolving needs of the organization over time. Example: One example of an IT non-functional requirement for agility could be the ability for a software system to quickly adapt to changing business requirements or market conditions. This could involve the ability to easily add or modify features, integrate with new technologies, or scale up or down as needed. The system should also be able to respond quickly to user feedback and incorporate changes into future releases. LOST view: Digital Solution Non-Functional Requirements Catalogue view Identifier: http://data.europa.eu/dr8/egovera/AgilityRequirement EIRA traceability: eira:DigitalSolutionNonFunctionalRequirementRequirement ABB name: egovera:AgilityRequirement EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-05-16 dct:identifier: http://data.europa.eu/dr8/egovera/AgilityRequirement dct:title: Agility Non-Functional Requirement Definition: Tiered levels of support is an IT non-functional requirement that refers to the different levels of technical support that are available to users of a system or application. This requirement specifies that the support should be provided in a hierarchical manner, with higher levels of support being available to users who require more advanced technical assistance. The purpose of this requirement is to ensure that users can receive the appropriate level of support based on their needs, and that technical issues can be resolved quickly and efficiently. This can help to minimize downtime and ensure that users are able to use the system or application effectively. Source: TOGAF Source reference: https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap03.html Additional information: According to the TOGAF specification, guidelines, and documentation, the non-functional requirement 'Tiered levels of support' refers to the need for a system or application to provide different levels of support based on the severity of the issue or problem. This requirement is typically associated with the availability and reliability of the system, as well as the ability to quickly resolve issues and minimize downtime. The tiered levels of support typically include three or more levels, with each level providing a different level of support and response time. The first level of support is typically a help desk or support team that provides basic troubleshooting and triage. The second level of support is typically a more specialized team that can provide more in-depth technical support and problem resolution. The third level of support is typically a team of experts who can provide advanced technical support and problem resolution. The tiered levels of support should be clearly defined and documented, with specific service level agreements (SLAs) for each level. The SLAs should include response times, resolution times, and escalation procedures. The system or application should also provide clear communication channels for users to report issues and receive updates on the status of their support requests. Overall, the 'Tiered levels of support' non-functional requirement is critical for ensuring the availability and reliability of a system or application, as well as providing users with timely and effective support when issues arise. Example: One example of the IT non-functional requirement 'Tiered levels of support' could be for a software application used by a large corporation. The requirement would specify that there must be multiple levels of support available to users, depending on the severity of the issue they are experiencing. For example, a user with a critical issue that is preventing them from completing their work would have access to a higher level of support than a user with a minor issue that can wait. This would ensure that the most urgent issues are addressed quickly and efficiently, while less urgent issues are still resolved in a timely manner. LOST view: Digital Solution Non-Functional Requirements Catalogue view Identifier: http://data.europa.eu/dr8/egovera/TieredLevelsOfSupportRequirement EIRA traceability: eira:DigitalSolutionNonFunctionalRequirementRequirement ABB name: egovera:TieredLevelsOfSupportRequirement EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-05-16 dct:identifier: http://data.europa.eu/dr8/egovera/TieredlevelsofsupportRequirement dct:title: Tiered levels of support Non-Functional Requirement Definition: Confidentiality is a non-functional requirement that ensures that sensitive information is protected from unauthorized access, disclosure, or modification. It is essential for maintaining the privacy and security of data, especially in industries such as healthcare, finance, and government. Confidentiality can be achieved through various measures, such as encryption, access controls, and secure communication channels. It is crucial to ensure that confidential information is only accessible to authorized personnel and is not compromised in any way. Source: TOGAF Source reference: https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap03.html Additional information: According to the TOGAF specification, confidentiality is a non-functional requirement that refers to the protection of sensitive information from unauthorized access, disclosure, or modification. This requirement is critical for ensuring the privacy and security of data, particularly in systems that handle sensitive or confidential information. To achieve confidentiality, the system must have appropriate security controls in place, such as access controls, encryption, and authentication mechanisms. These controls should be designed to prevent unauthorized access to data, both in transit and at rest, and to ensure that only authorized users can view or modify sensitive information. In addition, the system should be designed to detect and respond to security breaches or incidents that could compromise confidentiality. This may involve implementing intrusion detection and prevention systems, monitoring access logs, and conducting regular security audits and assessments. Overall, confidentiality is a key non-functional requirement that must be carefully considered and addressed in any system that handles sensitive or confidential information. By implementing appropriate security controls and monitoring mechanisms, organizations can ensure that their data remains secure and protected from unauthorized access or disclosure. Example: In a healthcare system, patient medical records must be kept confidential and only accessible to authorized personnel. LOST view: Digital Solution Non-Functional Requirements Catalogue view Identifier: http://data.europa.eu/dr8/egovera/ConfidentialityRequirement EIRA traceability: eira:DigitalSolutionNonFunctionalRequirementRequirement ABB name: egovera:ConfidentialityRequirement EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-05-16 dct:identifier: http://data.europa.eu/dr8/egovera/ConfidentialityRequirement dct:title: Confidentiality Non-Functional Requirement Definition: Recoverability is an important non-functional requirement in IT that refers to the ability of a system to solve failures or errors and come-back to its normal functioning. This includes the ability to recover data, configurations, and settings after a system crash or other disruptions. Recoverability is critical for ensuring system availability and minimizing downtime, as well as for protecting against data loss and corruption. It involves implementing backup and recovery mechanisms, such as data replication, redundancy, and failover, to ensure that the system can quickly and reliably recover from any failures or errors. Source: TOGAF Source reference: https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap03.html Additional information: According to the TOGAF specification, Recoverability is a non-functional requirement that refers to the ability of a system to recover from failures or disasters. It is a critical aspect of system design and architecture, as it ensures that the system can continue to operate even in the event of unexpected events. Recoverability includes a range of features and capabilities that enable a system to recover from failures, including backup and restore capabilities, fault tolerance, and disaster recovery planning. These features are designed to ensure that the system can quickly and efficiently recover from any type of failure, whether it is a hardware failure, software failure, or a natural disaster. To achieve recoverability, system architects and designers must consider a range of factors, including the system's overall architecture, the types of failures that are most likely to occur, and the impact of those failures on the system's operations. They must also consider the cost and complexity of implementing recoverability features, as well as the potential impact on system performance and availability. Overall, recoverability is a critical non-functional requirement that must be carefully considered and designed into any system architecture. By ensuring that a system can recover quickly and efficiently from failures, organizations can minimize downtime, reduce costs, and ensure that critical business operations can continue uninterrupted. Example: In a banking application, the recoverability non-functional requirement would ensure that in case of a system failure or crash, the system can recover all the data and transactions that were in progress before the failure occurred. This would ensure that no data is lost and the system can resume normal operations without any major disruptions. LOST view: Digital Solution Non-Functional Requirements Catalogue view Identifier: http://data.europa.eu/dr8/egovera/RecoverabilityRequirement EIRA traceability: eira:DigitalSolutionNonFunctionalRequirementRequirement ABB name: egovera:RecoverabilityRequirement EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-05-16 dct:identifier: http://data.europa.eu/dr8/egovera/RecoverabilityRequirement dct:title: Recoverability Non-Functional Requirement Definition: European Legal Act ABB is a Requirement enabling the adoption of laws by the Institutions of the European Union in order to exercise the powers given to them by the EU Treaties. They come in five forms: regulations, directives, decisions, recommendations and opinions. Source: Eur-Lex Source reference: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=LEGISSUM:ai0032 Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/EuropeanLegalActRequirement LOST view: Legal view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:EuropeanLegalActRequirement Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): TOLAR (https://tolar.io/)is a tool implemented as the outcome of the Seduproject, Hashnet is in the process of evaluation by the European Blockchain Partnership to become one of the pilot protocols for European Blockchain Service Infrastructure. https://www.seedeuproject.eu/partners/hashnet/ Interoperability Saliency: European Legal Act ABB is salient for legal interoperability because it helps to achieve European legal and juridical certainty in the exchange of information Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/EuropeanLegalActRequirement EIF Layer: Legal Definition: Authenticity is an IT non-functional requirement that ensures that the information or data presented is genuine and trustworthy. It is essential to maintain the integrity of the system and prevent unauthorized access or tampering of data. Authenticity can be achieved through various methods such as encryption, digital signatures, and access control mechanisms. It is crucial for systems that handle sensitive information, such as financial transactions, medical records, or legal documents, to ensure authenticity to maintain the trust of users and stakeholders. Source: TOGAF Source reference: https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap03.html Additional information: According to the TOGAF specification, Authenticity is a non-functional requirement that refers to the ability of a system to ensure that the information or data being processed or transmitted is genuine and has not been tampered with or altered in any way. This requirement is essential for systems that deal with sensitive or confidential information, such as financial transactions, personal data, or medical records. To meet the Authenticity requirement, the system must implement appropriate security measures, such as encryption, digital signatures, or access controls, to prevent unauthorized access, modification, or deletion of data. The system must also ensure that the data is accurate, complete, and consistent, and that it can be traced back to its original source. Furthermore, the system must provide mechanisms for detecting and reporting any attempts to tamper with the data, such as intrusion detection systems or audit logs. It must also have procedures in place for responding to security incidents, such as notifying the appropriate authorities or taking corrective actions to prevent further damage. Overall, the Authenticity requirement is critical for ensuring the integrity and trustworthiness of the system and the data it processes. It is a key component of a comprehensive security strategy and must be carefully considered and implemented to meet the needs of the organization and its stakeholders. Example: One example of the IT non-functional requirement 'Authenticity' could be ensuring that only authorized users have access to sensitive data or systems. This can be achieved through various authentication methods such as passwords, biometrics, or two-factor authentication. The system should also be able to detect and prevent unauthorized access attempts. LOST view: Digital Solution Non-Functional Requirements Catalogue view Identifier: http://data.europa.eu/dr8/egovera/AuthenticityRequirement EIRA traceability: eira:DigitalSolutionNonFunctionalRequirementRequirement ABB name: egovera:AuthenticityRequirement EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-05-16 dct:identifier: http://data.europa.eu/dr8/egovera/AuthenticityRequirement dct:title: Authenticity Non-Functional Requirement Definition: Learnability is an important non-functional requirement in IT that refers to the capability to learn and understand how to use a system or application. It is a measure of how quickly and efficiently users can become proficient in using the system, without requiring extensive training or support. Learnability is essential for ensuring user satisfaction and productivity, as well as reducing the risk of errors and mistakes. A system with good learnability should have clear and intuitive interfaces, consistent design patterns, and well-organized documentation and help resources. Source: TOGAF Source reference: https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap03.html Additional information: According to the TOGAF specification, Learnability is a non-functional requirement that refers to the ease with which users can learn to use a system or application. This requirement is essential for ensuring that users can quickly and easily understand how to use the system, reducing the need for extensive training and support. The Learnability requirement is typically addressed during the design and development phases of a project, with a focus on creating user-friendly interfaces, clear and concise documentation, and intuitive navigation. This requirement is closely related to other non-functional requirements, such as Usability, Accessibility, and User Experience (UX), which all contribute to the overall ease of use and satisfaction of the system. To ensure that the Learnability requirement is met, the TOGAF documentation recommends conducting user testing and feedback sessions throughout the development process. This allows developers to gather feedback from users and make adjustments to the system as needed to improve its ease of use and learnability. Overall, the Learnability requirement is critical for ensuring that users can quickly and easily learn to use a system or application, reducing the need for extensive training and support and improving overall user satisfaction. Example: One example of the IT non-functional requirement 'Learnability' could be for a new software application to have a user-friendly interface that is easy to navigate and understand, allowing users to quickly learn how to use the application without requiring extensive training or support. This could include clear and concise instructions, intuitive design elements, and helpful tooltips or pop-ups to guide users through the application's features and functionality. The goal of this requirement would be to minimize the learning curve for users and increase overall adoption and satisfaction with the software. LOST view: Digital Solution Non-Functional Requirements Catalogue view Identifier: http://data.europa.eu/dr8/egovera/LearnabilityRequirement EIRA traceability: eira:DigitalSolutionNonFunctionalRequirementRequirement ABB name: egovera:LearnabilityRequirement EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-05-16 dct:identifier: http://data.europa.eu/dr8/egovera/LearnabilityRequirement dct:title: Learnability Non-Functional Requirement Definition: Maintainability is an important non-functional requirement in IT that refers to the ease with which a software system can be modified, updated, or repaired. A maintainable system is one that can be easily understood, tested, and modified without causing any unintended consequences or errors. This requirement is critical for ensuring that the system can be adapted to changing business needs or technological advancements, and that it can be maintained over time without incurring excessive costs or downtime. Factors that contribute to maintainability include clear documentation, modular design, and adherence to coding standards and best practices. Source: TOGAF Source reference: https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap03.html Additional information: According to the TOGAF specification, Maintainability is a non-functional requirement that refers to the ease with which a system can be modified, updated, or repaired. This requirement is important because it ensures that the system can be adapted to changing business needs and technological advancements without incurring excessive costs or downtime. To achieve Maintainability, the system should be designed with modularity, scalability, and flexibility in mind. This means that the system should be composed of independent components that can be easily replaced or upgraded without affecting the rest of the system. Additionally, the system should be able to handle increased usage or data volumes without requiring significant changes to the underlying architecture. To ensure Maintainability, the system should also be well-documented and adhere to established coding standards and best practices. This will make it easier for developers to understand and modify the system as needed. Additionally, the system should be tested thoroughly to ensure that any changes or updates do not introduce new bugs or issues. Overall, Maintainability is an important non-functional requirement that ensures the long-term viability and adaptability of a system. By designing with Maintainability in mind, organizations can ensure that their systems remain effective and efficient in the face of changing business needs and technological advancements. Example: The software system should be designed in a way that allows for easy maintenance and updates to be made without disrupting the overall functionality of the system. This includes clear and concise documentation, modular code structure, and the ability to easily identify and fix bugs or errors. LOST view: Digital Solution Non-Functional Requirements Catalogue view Identifier: http://data.europa.eu/dr8/egovera/MaintainabilityRequirement EIRA traceability: eira:DigitalSolutionNonFunctionalRequirementRequirement ABB name: egovera:MaintainabilityRequirement EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-05-16 dct:identifier: http://data.europa.eu/dr8/egovera/MaintainabilityRequirement dct:title: Maintainability Non-Functional Requirement Definition: Architecture Building Block ABB is a Requirement constituting architecture model that describes a single aspect of the overall model. An Architecture Building Block describes generic characteristics and functionalities. Architecture Building Blocks are used to describe reference architectures, solution architecture templates or solution architectures of a specific solutions. Source: TOGAF Source reference: (https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap03.html#tag_03_8) Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): "Support" can be considered an architectural building block, when it is used in the context of the designing of a software that should include online or offline support to users.(https://www.brainkart.com/article/Functional-Requirements---Software-Architectures_11271/#:~:text=The%20following%20are%20examples%20of%20explicit%20architectural%20requirements%3A,Functionality%208%20Usability%209%20Reliability%20More%20items...%20) Identifier: http://data.europa.eu/dr8/ArchitectureBuildingBlockRequirement eira:ID: ABB608 ABB name: eira:ArchitectureBuildingBlockRequirement Definition: Non-binding Instrument ABB is a Business Object, involving no obligation, which are available to the European institutions to carry out their tasks. Source: EUR-Lex Source reference: http://ec.europa.eu/eurostat/data/data-validation Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/Non-bindingInstrumentRequirement LOST view: Legal view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:Non-bindingInstrumentRequirement Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Opinion of the European Economic and Social Committee on Next Generation SME Strategy — Enhancing Effective and Swift Delivery (own-initiative opinion). https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A52021IE3668&qid=1664779252884 Interoperability Saliency: The Non-binding Instrument ABB is a key salient for the legal and governance interoperability enabler as a specialisation of the Legal Act, it makes the recommendation of implementation of the policies and rules. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/Non-bindingInstrumentRequirement EIF Layer: Legal Definition: Latency is a non-functional requirement that refers to the time delay between the initiation of a request and the response received. It is a critical factor in determining the overall performance of a system, particularly in real-time applications such as online gaming, video conferencing, and financial trading. Low latency is desirable as it ensures that the system responds quickly to user requests, providing a seamless and efficient user experience. High latency, on the other hand, can lead to frustration and decreased productivity, making it essential to ensure that latency is kept to a minimum in any IT system. Source: TOGAF Source reference: https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap03.html Additional information: According to the TOGAF specification, Latency is a non-functional requirement that refers to the time delay between the initiation of a request and the response received. It is a measure of the time taken for data to travel from one point to another, and is typically measured in milliseconds (ms). Latency is an important consideration for IT systems that require real-time or near-real-time responses, such as financial trading systems, online gaming platforms, and video conferencing applications. High latency can result in delays, lag, and poor user experience, which can negatively impact the performance and usability of the system. To ensure that latency requirements are met, IT architects must consider a range of factors, including network bandwidth, server processing power, and data storage capacity. They must also design systems that are optimized for low latency, using techniques such as caching, load balancing, and content delivery networks (CDNs). In addition, IT architects must work closely with stakeholders to define latency requirements and establish appropriate performance metrics. This may involve conducting performance testing and benchmarking to identify areas for improvement and ensure that the system meets the required latency targets. Overall, latency is a critical non-functional requirement that must be carefully considered and managed throughout the IT system development lifecycle to ensure optimal performance and user experience. Example: An example of the IT non-functional requirement 'Latency' could be for a video conferencing application to have a maximum latency of 100 milliseconds to ensure smooth and real-time communication between participants. LOST view: Digital Solution Non-Functional Requirements Catalogue view Identifier: http://data.europa.eu/dr8/egovera/LatencyRequirement EIRA traceability: eira:DigitalSolutionNonFunctionalRequirementRequirement ABB name: egovera:LatencyRequirement EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-05-16 dct:identifier: http://data.europa.eu/dr8/egovera/LatencyRequirement dct:title: Latency Non-Functional Requirement Definition: Individual ABB is a Stakeholder that is a human being who may be dead or alive, but not imaginary. Source: SEMIC-CPV Source reference: https://semiceu.github.io/Core-Person-Vocabulary/releases/2.00/#Person Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/IndividualStakeholder LOST view: Organisational view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:IndividualStakeholder Interoperability Saliency: The Individual ABB is salient for organizational and behavioural interoperability because it permits the identification of procedures and business rules related to this stakeholder that facilitates the exchange of data, information and knowledge between digital public services and individuals (and vice versa). Synonym: Person Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Any instance of a person, for instance, Ursula von der Leyen, President of the European Commission. https://ec.europa.eu/commission/commissioners/2019-2024/president_en Interoperability Dimension: Structural IoP Viewpoint: Interoperability Privacy viewpoint Additional identifier: http://data.europa.eu/dr8/IndividualStakeholder EIF Layer: Organisational Definition: Organization ABB is a Stakeholder that corresponds to a collection of people organized together into a community or other social, commercial or political structure. The group has some common purpose or reason for existence which goes beyond the set of people belonging to it and can act as an Agent. Organizations are often decomposable into hierarchical structures. Source: SEMIC-CPOV Source reference: https://semiceu.github.io/CPOV/releases/2.1.0/#Organization Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/OrganisationStakeholder LOST view: Organisational view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:OrganisationStakeholder Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Any instance of an organisation with a legal personality, e.g. a Business, a Public Organisation, a Consortium, an NGO, etc. Interoperability Saliency: The Organization ABB is relevant for behavioural and organizational interoperability because it permits the identification of procedures, stakeholders and intra-company frameworks that facilitate the exchange of data, information and knowledge between digital public services. Interoperability Dimension: Structural IoP Viewpoint: Interoperability Privacy viewpoint Additional identifier: http://data.europa.eu/dr8/OrganisationStakeholder EIF Layer: Organisational Definition: Legal Entity ABB is a Stakeholder that is a self-empoyed person, company, or organization that has legal rights and obligations. Source: SEMIC-CBV Source reference: https://semiceu.github.io/Core-Business-Vocabulary/releases/2.00/#Legal%20Entity Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/LegalEntityStakeholder LOST view: Organisational view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:LegalEntityStakeholder Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Any instance of Business, Public Administration with legal personality or a Natural person. https://commission.europa.eu/publications/legal-entities_en Interoperability Saliency: The Legal Entity ABB is salient for organizational and behavioural interoperability because it permits the identification of procedures and business rules related to this stakeholder that facilitates the exchange of data, information and knowledge between digital public services. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/LegalEntityStakeholder EIF Layer: Organisational Definition: Public Administration ABB is a Stakeholder that corresponds to an Organization that is defined as being part of the public sector by a legal framework at any level. In this scope, there are in charge of implementing public policy Source: SEMIC-CPOV Source reference: https://semiceu.github.io/CPOV/releases/2.1.0/#Public%20Organisation Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/PublicAdministrationStakeholder LOST view: Organisational view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:PublicAdministrationStakeholder Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): The European Commission; the central, regional or local executive arm of a MS. Interoperability Saliency: The Public Administration ABB is salient for behavioural and organizational interoperability because it represents the specific authority in charge of supporting the definition of procedures and business rules to publish digital business capabilities. It also allows the security assurance and control configuration associated with this authority or public entity, the discovery of data types that it can provide, as well as other aspects necessary to assure, monitor and control the exchange of data between this public entity and the digital public services providing to or consuming data from this stakeholder. Additional information: The provision of digital public services are Public Administration's means of implementing e-Government. Certain countries make the difference between e-Government (policy implementation management) and e-Administration (administrative procedure management using electronic means). For these countries, the case of the SDG would fall under the e-Administration umbrella. Interoperability Dimension: Structural IoP Viewpoint: Interoperability Privacy viewpoint Additional identifier: http://data.europa.eu/dr8/PublicAdministrationStakeholder EIF Layer: Organisational Definition: Business ABB is a Stakeholder that correspond to an individual, group, or organization that has an interest or stake in the success or failure of a particular product or service. Indeed, they focus on making, buying or selling goods or even, providing services in pursuing a benefit. Source: Inspired in definition provided by relevant consultancy services Source reference: https://www.gartner.com/en/information-technology/glossary/business-process-as-a-service-bpaas Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/BusinessStakeholder LOST view: Organisational view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:BusinessStakeholder Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): The instance of an Economic Operator that is using a digital public service to submit a tender. Interoperability Saliency: The Business ABB is salient for behavioural and organizational interoperability because it permits the identification of a specific stakeholder, which in turn allows the identification of its rights, permissions, and digital business capabilities. It also allows the security assurance and control configuration associated with this stakeholder, the discovery of data types that it can provide, as well as other aspects necessary to assure, monitor and control the exchange of data between this stakeholder and the digital public services providing to or consuming data from this stakeholder. Interoperability Dimension: Structural IoP Viewpoint: Interoperability Privacy viewpoint Additional identifier: http://data.europa.eu/dr8/BusinessStakeholder EIF Layer: Organisational Definition: The Delivery Capacity Value ABB refers to the ability of public administrations to deliver public services, programs, and policies effectively and efficiently to citizens and stakeholders. It encompasses the overall performance, effectiveness, and responsiveness of public administration in meeting the needs and expectations of the public. Source: Public Administration Reform: A Comparative Analysis eira:iopDimension: Governance IoP LOST view: Enterprise Architecture Framework alignment guidelines view Identifier: http://data.europa.eu/dr8/DeliveryCapacityValue ABB name: eira:DeliveryCapacityValue EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-05-25 dct:identifier: http://data.europa.eu/dr8/DeliveryCapacityValue Definition: The Analytical Capacity Value ABB refers to the ability of public administrations to gather, analyse, and utilize data and evidence in decision-making processes. It involves having the skills, tools, and institutional arrangements to collect, interpret, and apply data to inform policy development, program design, and performance monitoring. Source: Public Administration Reform: A Comparative Analysis eira:iopDimension: Governance IoP LOST view: Enterprise Architecture Framework alignment guidelines view Identifier: http://data.europa.eu/dr8/AnalyticalCapacityValue ABB name: eira:AnalyticalCapacityValue EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-05-25 dct:identifier: http://data.europa.eu/dr8/AnalyticalCapacityValue Definition: The Coordination Capacity Value ABB refers to mediating and bringing different administrative units and dispersed actors to work together to achieve joint actions. It is not only about vertical coordination by hierarchy but also about facilitating horizontal coordination across policy areas and organizations at the same administrative level. Source: Administrative coordination capacity; does the wickedness of policy areas matter? Source reference: https://www.duo.uio.no/bitstream/handle/10852/76072/10-108014494035-2019-1584147.pdf?sequence=4&isAllowed=y eira:iopDimension: Governance IoP LOST view: Enterprise Architecture Framework alignment guidelines view Identifier: http://data.europa.eu/dr8/CoordinationCapacityValue ABB name: eira:CoordinationCapacityValue EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-05-25 dct:identifier: http://data.europa.eu/dr8/CoordinationCapacityValue Definition: The Regulatory Capacity Value ABB relates to a government's ability to develop, implement, and enforce regulations and rules effectively. It involves having the necessary resources, expertise, and mechanisms in place to establish and enforce regulatory frameworks that protect public interests, promote compliance, and achieve desired outcomes. Source: Public Administration Reform: A Comparative Analysis eira:iopDimension: Governance IoP LOST view: Enterprise Architecture Framework alignment guidelines view Identifier: http://data.europa.eu/dr8/RegulatoryCapacityValue ABB name: eira:RegulatoryCapacityValue EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-05-25 dct:identifier: http://data.europa.eu/dr8/RegulatoryCapacityValue Definition: Digitaliation Roadmap ABB is a Work Package that corresponds to a high-level vision and strategy referring to long-term business goal an organization wants to achieve, including digital initiatives and goals the organization will drive. Source: Inspired in referent consultancy companies and IEEE Source reference: https://roadmaps.ieee.org/guide-to-technology-roadmaps Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/DigitalisationRoadmapWorkPackage LOST view: Organisational view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:DigitalisationRoadmapWorkPackage Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Digital roadmap for organising mobility authorities (OMAs). (https://cerre.eu/publications/mobility-as-a-service-maas-digital-roadmap-public-transport-authorities/) Interoperability Saliency: Digitalization Roadmap ABB is salient for the governance, semantic and technical interoperability because it commonly offers (i) a transversal vision of existing reusable standards applied in the digitalization of the public sector, (ii) actions to ensure data exchange between digital services; (iii) technological software and assets that should be included in the digitalization of public administrations. Interoperability Dimension: Governance IoP Viewpoint: Interoperability Governance viewpoint Additional identifier: http://data.europa.eu/dr8/DigitalisationRoadmapWorkPackage EIF Layer: Organisational Definition: Security Enablers ABB is a Grouping that refers to components that enable the implementation and management of security controls and measures, and enable organizations to protect their digital assets and information from a wide range of cyber threats Source: Inspired n Cyber Resilience Act Source reference: https://digital-strategy.ec.europa.eu/en/library/cyber-resilience-act Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/SecurityEnablersGrouping LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:SecurityEnablersGrouping Interoperability Saliency: The Security Enablers Grouping ABB is salient for interoperability because it aggregates the set of services and components that allow to secure systems and protect them from cyber threats. In this sense, security can play a relevant role, making systems safe and as consequence, ensuring their integrity. All these aspects can contribute to the development of an interoperable and secure environment of digital public services. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/SecurityEnablersGrouping EIF Layer: TechnicalApplication Definition: Digital Public Service Operation Principle Catalogue ABB is a grouping that covers a range of principles and guidelines that are essential for the operation of digital public services. These principles include convergence control on public policy goals attainment, data accessibility, data findability, data interoperability, data reusability, preservation of information, security by design, and trust. Source: EIRA Team Research Additional information: The Digital Public Service Operation Principle Catalogue ABB is a comprehensive collection of principles that guide the operation of digital public services. 'Convergence control on public policy goals attainment' refers to the alignment of digital services with public policy goals. 'Data Accessibility' and 'Data Findability' pertain to the ease of access and discovery of data respectively. 'Data Interoperability' and 'Data Reusability' concern the ability of systems to work together and the potential for data to be reused. 'Preservation of information' is about maintaining and protecting data, while 'Security by Design' is a principle that emphasizes the importance of incorporating security measures from the onset of system design. Lastly, 'Trust' refers to the confidence and reliability in digital public services. Example: An example of the application of these principles can be seen in a digital public service like an online tax filing system. The system should be designed with 'Security by Design', ensuring that user data is protected. The data collected should be 'Accessible' and 'Findable' for users, and 'Interoperable' to allow for seamless interaction with other systems. The system should also allow for 'Data Reusability', enabling data to be used for multiple purposes. The 'Preservation of Information' is crucial to maintain historical tax records. The system should also align with the 'Convergence control on public policy goals attainment' by facilitating the efficient collection of taxes. Lastly, the system should foster 'Trust' among users by being reliable and secure. LOST view: Architecture Principles view Identifier: http://data.europa.eu/dr8/egovera/DigitalPublicServiceOperationPrincipleCatalogueGrouping ABB name: egovera:DigitalPublicServiceOperationPrincipleCatalogueGrouping EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-08-18 dct:identifier: http://data.europa.eu/dr8/egovera/DigitalPublicServiceOperationPrincipleCatalogueGrouping dct:title: Digital Public Service Operation Principle Catalogue Catalogue Definition: Networking Infrastructure Enablers ABB is a Grouping of components and services that facilitate the creation and operation of computer networks. These enablers can include both hardware and software technologies and are essential for building and maintaining modern networks Source: ISA2 - EIA Action Source reference: https://ec.europa.eu/isa2/actions/towards-european-interoperability-architecture_en/ Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/NetworkingInfrastructureEnablersGrouping LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:NetworkingInfrastructureEnablersGrouping Synonym: Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): ECC Report 301. https://docdb.cept.org/download/1395 Interoperability Saliency: The Networking Infrastructure Enablers ABB is salient for the organizational and technical interoperability due to it provides (i) the set up of rules for establishing the correct communication in the public administration considering both public and private, (ii) establish the physical elements to balance the traffic and ensure the correct behaviour of the communication considering the system performance. Additional information: Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/NetworkingInfrastructureEnablersGrouping EIF Layer: TechnicalInfrastructure Definition: Management Infrastructure Enablers ABB is a Grouping that refers to the set of components and services to manage a public administration IT platforms efficiently and efficiency. Source: Inspired in PMI Source reference: https://www.pmi.org/learning/library/project-management-infrastructure-4647 Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/ManagementInfrastructureEnablersGrouping LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:ManagementInfrastructureEnablersGrouping Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Design Principles for Data Spaces -Position Paper. https://design-principles-for-data-spaces.org/ Interoperability Saliency: Management Infrastructure Enablers ABB is salient for technical interoperability due to its set-up the implementation for managing and monitoring the public administration digital services to (i) ensure their correct behaviour, (ii) ensure the correct provision of resources, and (iii) guarantee the assessment of standards and regulations (including SLAs) Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/ManagementInfrastructureEnablersGrouping EIF Layer: TechnicalInfrastructure Definition: Jurisdiction ABB is a Grouping that refers to the limits or territory within which authority may be exercised. Source: CPV Source reference: https://semiceu.github.io/Core-Person-Vocabulary/releases/2.00/#Jurisdiction Definition: Machine Translation Enablers ABB is a Groping that refers to tools or components that facilitate the translation of text from one language to another using machine learning techniques Source: Inspired in eTranslation Source reference: https://commission.europa.eu/resources-partners/etranslation_en Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/TranslationEnablersGrouping LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:TranslationEnablersGrouping Interoperability Saliency: The Translation Enablers Grouping ABB is salient for technical interoperability because it comprises a set of tools and components that ensure the translation of digital public services to different languages in the European Union by using machine learning techniques. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/TranslationEnablersGrouping EIF Layer: TechnicalApplication Definition: Observability Requirements Catalogue ABB is a grouping that covers non-functional requirements related to system monitoring, logging, and tiered levels of support. These requirements are critical for ensuring the reliability, availability, performance, security, and effective use of IT systems and applications. Source: EIRA Team Research Additional information: The Observability Requirements Catalogue ABB includes three main elements: Alerts and Monitoring, Logging, and Tiered Levels of Support. Alerts and Monitoring refer to the system's ability to detect and report issues or anomalies in real-time, ensuring optimal performance and availability. Logging involves recording events and activities within a system or application, providing a detailed record of system behavior for troubleshooting, auditing, and analysis. Tiered Levels of Support refers to the hierarchical provision of technical support to users based on their needs, ensuring quick and efficient resolution of technical issues. These requirements are essential for maintaining the security and reliability of IT systems, meeting regulatory compliance requirements, minimizing downtime, and enabling effective use of the system or application. Example: Examples of application for the Observability Requirements Catalogue ABB include: a cloud-based software application implementing real-time alerts and monitoring to detect and report system errors, a banking system implementing logging to record user actions and system errors for auditing and analysis, and a customer support center implementing tiered levels of support to provide appropriate technical assistance to users based on their needs. LOST view: Digital Solution Non-Functional Requirements Catalogue view Identifier: http://data.europa.eu/dr8/egovera/ObservabilityRequirementsCatalogueGrouping ABB name: egovera:ObservabilityRequirementsCatalogueGrouping EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-08-17 dct:identifier: http://data.europa.eu/dr8/egovera/ObservabilityRequirementsCatalogueGrouping dct:title: Observability Requirements Catalogue Catalogue Definition: Digital Workplace Enablers is a Grouping that refers to components or services that enable the collaboration of work aspects while security and privacy are ensured. Source: European Comission Source reference: https://ec.europa.eu/info/publications/digital-workplace-strategy_en Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/DigitalWorkplaceEnablersGrouping LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:DigitalWorkplaceEnablersGrouping Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Set of IT tools used by European Commission officials, workers, etc. There is a new strategy put in place by the Commission to improve the work of the different roles involved. https://europa.eu/digitec/news/digital-workplace-european-commission/ Interoperability Saliency: The Digital Workplace Enablers Grouping ABB is salient for technical interoperability because it tools, components or services that allow the free collaboration of work aspects while security and privacy are ensured. The free collaboration is relevant for interoperability because allows to enable and maintain digital public services without the need of being at the Organisation responsible for digital public services head quarters Interoperability Dimension: Behavioral IoP Additional identifier: http://data.europa.eu/dr8/DigitalWorkplaceEnablersGrouping EIF Layer: TechnicalApplication Definition: Privacy Enablers ABB is a Grouping that refers to components and services that facilitate the implementation of privacy-related functionality within an application or system Source: ePrivacy Regulation Source reference: https://digital-strategy.ec.europa.eu/en/policies/eprivacy-regulation Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/PrivacyEnablersGrouping LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:PrivacyEnablersGrouping Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): SOLVIT - Solvit is a mailbox service for the access, rectification or deletion of personal data.(http://ec.europa.eu/solvit/privacy-statement/#maincontentSec8) Interoperability Saliency: The Privacy Enablers Grouping ABB is salient for technical interoperability because it comprises tools and components that facilitate the implementation of privacy-related functionality within an application or system. This is relevant for the implementation and deployment of digital public services. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/PrivacyEnablersGrouping EIF Layer: TechnicalApplication Definition: Agility Requirements Catalogue ABB is a grouping that covers a set of IT non-functional requirements that contribute to the agility of a software or system. These requirements, including configurability, compatibility, maintainability, and deployability, are crucial for ensuring that the system can adapt to changing needs and environments, can function seamlessly with other systems, can be easily modified and maintained, and can be efficiently deployed and installed. Source: EIRA Team Research Additional information: The Agility Requirements Catalogue ABB comprises of four key elements: Configurability, Compatibility, Maintainability, and Deployability. Configurability refers to the system's ability to be easily customized or modified to meet specific needs, without requiring extensive programming knowledge. Compatibility ensures that the system can function properly with other systems, hardware, or environments, and can be easily upgraded or migrated. Maintainability refers to the ease with which the system can be modified, updated, or repaired, contributing to its long-term sustainability. Deployability involves the ease and efficiency with which the software can be deployed and installed on different platforms, reducing downtime and minimizing risk of errors. Example: An example of the application of the Agility Requirements Catalogue ABB could be in the development of a new software system. The developers would need to ensure that the system is configurable, allowing users to easily customize it to their needs. They would also need to ensure that it is compatible with a range of other systems, software, and hardware to ensure wide usability. The system should be maintainable, with clear documentation and a modular design to allow for easy updates and repairs. Finally, the system should be easily deployable, with a straightforward installation process that minimizes disruption to the existing system. LOST view: Digital Solution Non-Functional Requirements Catalogue view Identifier: http://data.europa.eu/dr8/egovera/AgilityRequirementsCatalogueGrouping ABB name: egovera:AgilityRequirementsCatalogueGrouping EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-08-17 dct:identifier: http://data.europa.eu/dr8/egovera/AgilityRequirementsCatalogueGrouping dct:title: Agility Requirements Catalogue Catalogue Definition: Not Implemented Architecture Principles Catalogue ABB is a grouping that covers the collection of architecture principles that have not been implemented in a specific solution architecture. It serves as a repository for documenting these omissions, providing transparency and understanding of the architectural choices made. Source: EIRA Team Research Additional information: Despite the vital role architecture principles play, there are situations where certain principles may not be employed within a specific solution architecture. The Not Implemented Architecture Principles Catalogue ABB serves as a repository for documenting such cases. Including explanatory notes alongside each omitted principle is crucial. These notes should provide a clear rationale for the exclusion, explaining the context, constraints, or trade-offs that led to the decision. The catalogue facilitates knowledge sharing among architects by capturing the context and rationale behind each omitted principle. It also helps ensure that architectural decisions align with organizational governance frameworks and compliance requirements. Furthermore, it enables architects to proactively address potential risks and develop mitigation strategies. The documentation of omitted principles promotes a culture of continuous improvement, encouraging architects to revisit decisions, reassess trade-offs, and learn from past experiences. Example: For instance, an architecture principle related to the use of open standards may not be implemented in a solution architecture due to vendor lock-in or specific business requirements. This omission would be documented in the Not Implemented Architecture Principles Catalogue ABB, along with an explanation of the reasons for the deviation. This documentation would then serve as a reference for future architects, helping them understand the trade-offs made and informing their decision-making process. LOST view: Architecture Principles view Identifier: http://data.europa.eu/dr8/egovera/NotImplementedArchitecturePrinciplesCatalogueGrouping ABB name: egovera:NotImplementedArchitecturePrinciplesCatalogueGrouping EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-08-18 dct:identifier: http://data.europa.eu/dr8/egovera/NotImplementedArchitecturePrinciplesCatalogueGrouping dct:title: Not Implemented Architecture Principles Catalogue Catalogue Definition: Computing Infrastructure Enablers ABB is a Grouping that refers to components and services that provide the development, deployment, and management of virtual and computing infrastructure Source: Inspired in Redhat Source reference: https://www.redhat.com/en/topics/virtualization/what-is-a-virtual-machine Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/ComputingInfrastructureEnablersGrouping LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:ComputingInfrastructureEnablersGrouping Synonym: Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): DIGIT/C Hosting Service - DIGIT/C offers a high availability and high performance hosting infrastructure that is being comprised, among other elements, of back-end web server instances and application servers for hosting and serving both static and dynamic sites. http://ec.europa.eu/ipg/build/infrastructure/index_en.htm Interoperability Saliency: The Computing Infrastructure Enablers ABB is salient for organizational and technical interoperability due to it providing (i) mechanisms to ensure the correct publication of public administration digital services, and (ii) physical elements that permit to host of public administration services in a standardised manner. Additional information: Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/ComputingInfrastructureEnablersGrouping EIF Layer: TechnicalInfrastructure Definition: Semantic Functional Content ABB is a Grouping that refers to the procedures and mechanims to structure and organise the information to convey meaning and functionality. Source: Inspired in "Semantic Content" article Source reference: https://philpapers.org/rec/STOSC-2 Identifier: http://data.europa.eu/dr8/SemanticFunctionalContentGrouping eira:ID: http://data.europa.eu/dr8/SemanticFunctionalContentGrouping ABB name: eira:SemanticFunctionalContentGrouping Definition: Data Management Enablers ABB is a Grouping that refers to components and services that support effective data management practices and procedures. Source: Inspired in European Comision- Data Governance and data policies at the European Comission Source reference: https://commission.europa.eu/publications/data-governance-and-data-policies-european-commission_en Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/DataManagementEnablersGrouping LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:DataManagementEnablersGrouping Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Context Broker as a CEF Building Block. https://ec.europa.eu/digital-building-blocks/wikis/download/attachments/82773424/Context%20Broker%20Brochure.pdf?version=1&modificationDate=1558016168498&api=v2 Interoperability Saliency: The Data Management Enablers Grouping ABB is salient for technical interoperability because it comprises the tools, components and services related to data management. Data Management Enablers are relevant as they support effective and efficient data management, ensuring that interoperability can be achieved between digital public services. Additional identifier: http://data.europa.eu/dr8/DataManagementEnablersGrouping EIF Layer: TechnicalApplication Definition: Data Lake Infrastructure Enablers ABB is a Grouping of a set of tools and digital services hat help organizations build and maintain a robust data lake infrastructure Source: Inspired in Forbes Source reference: https://www.forbes.com/sites/ciocentral/2011/07/21/big-data-requires-a-big-new-architecture/?sh=5be8fb361157 Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/DataLakeInfrastructureEnablersGrouping LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:DataLakeInfrastructureEnablersGrouping Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Smart Data Lake. https://smartdatalake.eu/ Interoperability Saliency: Data Lake Infrastructure Enabers ABB is salient for semantic and technical interoperability because it determines the needed infrastructure to host data management considering multiple data sources. This ABB also implements analytical services for ensuring data quality of the stored information. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/DataLakeInfrastructureEnablersGrouping EIF Layer: TechnicalInfrastructure Definition: User Experience Management Enablers ABB is a Grouping that refers to components and services that track, measure, analyze and improve any interaction people have with the organization Source: Inpired in referece business and cloud provider compabies Source reference: https://www.vmware.com/topics/glossary/content/experience-management.html Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/UserExperienceManagementEnablersGrouping LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:UserExperienceManagementEnablersGrouping Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Mi Carpeta Ciudadana Carpeta Ciudadana is a personal online space that facilitates your relationship with public administrations. https://carpetaciudadana.gob.es/carpeta/clave.htm Interoperability Saliency: The User Experience Management Enablers Grouping ABB is salient for technical interoperability because it comprises services and components that allow different parties involved in the use and delivery o public services, to exchange and provide data or information. Interoperability Dimension: Behavioral IoP Additional identifier: http://data.europa.eu/dr8/UserExperienceManagementEnablersGrouping EIF Layer: TechnicalApplication Definition: Wide Area Networking ABB is a Grouping of different of networks to enables communication and data exchange across geographically dispersed locations Source: Gartner Source reference: https://www.gartner.com/en/information-technology/glossary/wan-wide-area-network Definition: Analytics Infrastructure Enablers ABB is a Grouping that refers to the set of components and services that support the development and deployment of data analytics solutions Source: Inspired in CROS Source reference: https://ec.europa.eu/eurostat/cros/content/36-strategy-european-data-infrastructure_en Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/AnalyticsInfrastructureEnablersGrouping LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:AnalyticsInfrastructureEnablersGrouping Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Central banks increasingly need to use business intelligence (BI) systems to collect, manage and analyse data in order to inform policy decisions. This report presents the results of a survey conducted by the BIS’s Irving Fisher Committee on Central Bank Statistics (IFC) in 2019. The following link gives access to a report on the use of BI in Central Banks. https://www.bis.org/ifc/publ/ifc_report_bi_1910.pdf Interoperability Saliency: Analytics Infrastructure Enablers ABB is salient for the semantic and organizational interoperability because it sets the analytical environments that relate to (i) data processing of a large amount of data, (ii) data visualization and interaction, and (iii) catalogues discovery and data sharing across multiple workspaces. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/AnalyticsInfrastructureEnablersGrouping EIF Layer: TechnicalInfrastructure Definition: API Enablers ABB is a Grouping that refers to components and frameworks that support the implementation and cataloguing of (open) software interfaces Source: European Comission Source reference: https://digital-strategy.ec.europa.eu/en/library/apis-enablers-digital-transformation-governments Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/APIEnablersGrouping LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:APIEnablersGrouping Interoperability Saliency: The API Enablers Grouping ABB is salient for technical interoperability because this grouping composition of the different technologies that can implement software interfaces used to consume and provide data from public services. Implementing those technologies can enable interoperability throughout public services. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/APIEnablersGrouping EIF Layer: TechnicalApplication Definition: Trust Enablers ABB is a Grouping that refers to components and services that facilitate the establishment and maintenance of secure-cross borders transactions and interactions. Source: Inspired in eIDAS Source reference: http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv%3AOJ.L_.2014.257.01.0073.01.ENG LOST view: Technical view - application Interoperability saliency: The Trust Enablers Grouping is salient for interoperability because it comprises the set of tools, services and applications that allow to secure the digital public services across borders. Trust enablers are focused on transactions and interactions between parties (services, platforms, individuals) related to services. By applying those mechanisms identities, and timestamps (amongst other aspects) can be guaranteed and ensure the trustworthy data exchange Identifier: http://data.europa.eu/dr8/TrustEnablersGrouping eira:ID: http://data.europa.eu/dr8/TrustEnablersGrouping ABB name: eira:TrustEnablersGrouping EIRA concept: eira:ArchitectureBuildingBlock Definition: Trust Infrastructure Enablers ABB is a Grouping of a set of components and services devoted to creating and managing public keys for encryption, which is a common method of securing data transfers on the internet Source: ENISA Source reference: https://www.enisa.europa.eu/topics/incident-response/glossary/public-key-infrastructure-pki Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/TrustInfrastructureEnablersGrouping LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:TrustInfrastructureEnablersGrouping Synonym: Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): eDelivery - PKI Service. https://ec.europa.eu/digital-building-blocks/wikis/display/DIGITAL/PKI+Service Interoperability Saliency: Trust Infrastructure Enablers ABB is salient for organizational interoperability because it defines the rules and methodologies to ensure the secure and trustworthy exchange of information between public services. Additional information: Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/TrustInfrastructureEnablersGrouping EIF Layer: TechnicalInfrastructure Definition: Digital Public Service Improvement Principle Catalogue ABB is a grouping that covers the principles, guidelines, and strategies aimed at enhancing the delivery of public services through digital platforms. The catalogue primarily focuses on the principle of 'Innovation', which is a key driver in the modernization and improvement of public services. Source: EIRA Team Research Additional information: The Digital Public Service Improvement Principle Catalogue ABB is an essential tool for public service organizations seeking to leverage digital technologies to improve their service delivery. The catalogue's main element is 'Innovation', which refers to the application of new ideas, methods, or technologies to enhance public service delivery. Innovation in this context can involve the development of new digital services, the improvement of existing services through digital technologies, or the use of digital technologies to create new ways of engaging with the public. The catalogue provides a framework for understanding and applying the principle of innovation in the context of digital public service improvement. Example: An example of the application of the Digital Public Service Improvement Principle Catalogue ABB could be a local government agency using it as a guide to develop a new online service for residents to report issues in their community. The agency could use the principle of 'Innovation' to explore new ways of receiving and responding to reports, such as through a mobile app or a chatbot, thereby improving the efficiency and accessibility of their service. LOST view: Architecture Principles view Identifier: http://data.europa.eu/dr8/egovera/DigitalPublicServiceImprovementPrincipleCatalogueGrouping ABB name: egovera:DigitalPublicServiceImprovementPrincipleCatalogueGrouping EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-08-18 dct:identifier: http://data.europa.eu/dr8/egovera/DigitalPublicServiceImprovementPrincipleCatalogueGrouping dct:title: Digital Public Service Improvement Principle Catalogue Catalogue Definition: Blockchain Enablers ABB is a Grouping that refers to components and services that facilitate the development, deployment, and management of ledger technology applications Source: Inspired in European Blockchain Strategy Source reference: https://digital-strategy.ec.europa.eu/en/library/european-blockchain-strategy-brochure Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Fishcoin Project, is a project using Blockchain technologies for seafood traceability. https://fishcoin.co/ LOST view: Technical view - application Interoperability saliency: The Blockchain Enablers Grouping ABB is salient for interoperability because it comprises the tools, applications and services relevant to implement and deploying ledger technologies into digital public services. Identifier: http://data.europa.eu/dr8/BlockchainEnablersGrouping ABB name: eira:BlockchainEnablersGrouping EIRA concept: eira:ArchitectureBuildingBlock eira:PID: http://data.europa.eu/dr8/BlockchainEnablersGrouping Definition: Digital Public Service Design Principle Catalogue ABB is a grouping that covers a range of principles and guidelines aimed at shaping the design and implementation of digital public services. These principles encompass various aspects including administrative simplification, carbon-dioxide e-footprint impact awareness, code of ethics compliance, data portability, EU legislation compliance, integrated user experience, multilingualism, privacy, proactiveness, service orientation, technology neutrality, and user-centricity among others. Source: EIRA Team Research Additional information: The Digital Public Service Design Principle Catalogue ABB is a comprehensive collection of principles that guide the design and delivery of digital public services. These principles are aimed at ensuring that digital services are user-centric, efficient, ethical, and compliant with relevant legislation. They cover a broad spectrum of considerations from administrative simplification which aims to reduce bureaucratic processes and make public services more accessible, to carbon-dioxide e-footprint impact awareness which encourages the design of digital services that are environmentally friendly. Other principles like data portability and privacy ensure that users' data is handled responsibly and securely. The catalogue also includes principles like multilingualism and integrated user experience which aim to make digital services more inclusive and user-friendly. Example: An example of application of these principles can be seen in the design of a digital public service like an online tax filing system. The system would need to be designed with user-centricity in mind, ensuring it is easy to use for all citizens. It would also need to comply with EU legislation and a code of ethics, ensuring data is handled securely and responsibly. The system should also be designed with an awareness of its carbon-dioxide e-footprint, aiming to minimise its environmental impact. Furthermore, the principle of administrative simplification would be applied to make the tax filing process as straightforward and efficient as possible. LOST view: Architecture Principles view Identifier: http://data.europa.eu/dr8/egovera/DigitalPublicServiceDesignPrincipleCatalogueGrouping ABB name: egovera:DigitalPublicServiceDesignPrincipleCatalogueGrouping EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-08-18 dct:identifier: http://data.europa.eu/dr8/egovera/DigitalPublicServiceDesignPrincipleCatalogueGrouping dct:title: Digital Public Service Design Principle Catalogue Catalogue Definition: Identity and Access Infrastructure Enablers ABB is a Grouìng of a set of components and services that provide the underlying functionality to implement identity and access management solutions Source: Inspired in CAMSS Source reference: https://joinup.ec.europa.eu/collection/common-assessment-method-standards-and-specifications-camss Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/IdentityAndAccessInfrastructureEnablersGrouping LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:IdentityAndAccessInfrastructureEnablersGrouping Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Lightweight Directory Access Protocol can be implemented in multiple platforms or systems, allowing to integrating an organisatio'n LDAP-enabled identity management service to other platforms such as Drupal. https://www.drupal.org/docs/contributed-modules/lightweight-directory-access-protocol-ldap Interoperability Saliency: Identity and Access Infrastructure Enablers ABB is Salient for the technical, organizational and semantic interoperability because it provides (i) the setup and implementation of rules to access public services, (ii) the tools and mechanism to identify unequivocally organizations or individuals, (iii) the tools and mechanisms to facilitate the access and use of the public services Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/IdentityAndAccessInfrastructureEnablersGrouping EIF Layer: TechnicalInfrastructure Definition: Artificial Intelligence Enablers ABB is a Grouping that refers to components and services that provide the necessary infrastructure and resources for AI developers to build intelligent systems that can perform tasks that typically require human-like intelligence, such as perception, reasoning, learning, and decision-making Source: European Comision Source reference: https://digital-strategy.ec.europa.eu/en/library/definition-artificial-intelligence-main-capabilities-and-scientific-disciplines Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/ArtificialIntelligenceEnablersGrouping LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:ArtificialIntelligenceEnablersGrouping Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): PyTorch is a machine learning framework based on the Torch library, used for applications such as computer vision and natural language processing, originally developed by Meta AI and now part of the Linux Foundation umbrella. It is free and open-source software released under the modified BSD license. Although the Python interface is more polished and the primary focus of development, PyTorch also has a C++ interface. https://pytorch.org/ Interoperability Saliency: The Artificial Intelligence Enablers Grouping ABB is salient for technical interoperability because it comprises tools and services that provide the necessary infrastructure and resources for AI developers to build intelligent systems that can perform tasks that typically require human-like intelligence, such as perception, reasoning, learning, and decision-making. This can contribute to enabling and creating cutting-edge digital public services interoperable with others. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/ArtificialIntelligenceEnablersGrouping EIF Layer: TechnicalApplication Definition: Digital Exchange Enablers ABB is a Grouping that refers to tools or components that facilitate the exchange of data between systems or applications Source: EIFv2 Source reference: http://ec.europa.eu/isa/documents/isa_annex_ii_eif_en.pdf Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/DataExchangeEnablersGrouping LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:DataExchangeEnablersGrouping Example: The Data Exchange Service ABB  is salient for technical interoperability because it provides secure and trustworthy data exchange between different ICT systems as stated in the EIF: "Define a common security and privacy framework and establish processes for public services to ensure secure and trustworthy data exchange between public administrations and in interactions with citizens and businesses." Interoperability Saliency: The Data Exchange Enablers Grouping ABB is salient for technical interoperability because it provides secure and trustworthy data exchange between different ICT systems as stated in the EIF: "Define a common security and privacy framework and establish processes for public services to ensure secure and trustworthy data exchange between public administrations and in interactions with citizens and businesses." Interoperability Dimension: Behavioral IoP Additional identifier: http://data.europa.eu/dr8/DataExchangeEnablersGrouping EIF Layer: TechnicalApplication Definition: Data Analytics Enablers ABB is a Grouping that refers to components and services that serve any current or future Digital Service Infrastructure (DSI) requiring data analysis capabilities. Source: Inspired in Data Act Source reference: https://digital-strategy.ec.europa.eu/en/policies/data-act Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/AnalyticsEnablersGrouping LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:AnalyticsEnablersGrouping Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Microsoft Power BI - Power BI is a business analytics service by Microsoft. It aims to provide interactive visualizations and business intelligence capabilities with an interface simple enough for end users to create their own reports and dashboards. It is part of the Microsoft Power Platform.(https://powerbi.microsoft.com/it-it/what-is-power-bi/) Interoperability Saliency: The Analytics Enablers Grouping ABB is salient for technical Interoperability because it comprises tools and services that serve to digital service infrastructure of current or future digital services. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/AnalyticsEnablersGrouping EIF Layer: TechnicalApplication Definition: Knowledge discovery Enablers ABB is a Grouping that refers to components and services that facilitate the process of discovering insights and knowledge from data Source: European Comission-Open Science Source reference: https://research-and-innovation.ec.europa.eu/strategy/strategy-2020-2024/our-digital-future/open-science_en Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/KnowledgeDiscoveryEnablersGrouping LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:KnowledgeDiscoveryEnablersGrouping Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): CELLAR. Cellar metadata is stored in a knowledge graph, and more specifically in a triple store. A SPARQL interface is used to query the metadata. https://op.europa.eu/en/web/cellar/cellar-data/metadata/knowledge-graph Interoperability Saliency: The Knowledge Discovery Enablers Grouping ABB is salient for technical interoperability because it comprises tools, data services and components that enable and enhance the knowledge discovery process from data and information. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/KnowledgeDiscoveryEnablersGrouping EIF Layer: TechnicalApplication Definition: Shared Knowledge Content ABB is a Grouping setting semantic (re)usable resources, with convergence power, in relation to public policy goals attainment, enabling to reuse and share a common understanding from existing data, information and services across public administrations across borders. Source: Atlassian Source reference: https://www.atlassian.com/itsm/knowledge-management/what-is-a-knowledge-base Last modification: 2023-11-20 Identifier: http://data.europa.eu/dr8/SharedKnowledgeContentGrouping LOST view: Semantic view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:SharedKnowledgeContentGrouping Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Eur-Lex (stylized EUR-Lex) is an official website of European Union law and other public documents of the European Union (EU), published in 24 official languages of the EU. The Official Journal (OJ) of the European Union is also published on Eur-Lex. Users can access Eur-Lex free of charge and also register for a free account, which offers extra features. https://eur-lex.europa.eu/homepage.html?locale=en Interoperability Saliency: The Shared Knowledge Content ABB is a key interoperability enabler (*) for governance, behavioural and structural interoperability. This ABB is salient for semantic interoperability with public policy goals convergence value by enabling i) the provision/consumption of data by public services, ii) the exchange of data, information, and knowledge between digital public services, and iii) collaboration between digital public services Additional information: This convergence power is based on the enabling sense-making nature of these resources influencing the enactment of common understanding from the existing organisational information. The degree of achievement could range from an ideal perfect shared knowledge base (i.e. no interoperability barriers from the semantic perspective) to an imperfect or even null shared knowledge base (i.e. some interoperability barriers from the semantic perspective). The level of semantic interoperability will constrain digital public services cross levels in a public administration, cross public administrations, and cross borders. The shared knowledge base enables: i) structural interoperability with semantic resources supporting reusing and/or sharing of digital public services (i.e. data set catalogue); ii) behavioural interoperability with semantic resources supporting exchanging capabilities of data, information or knowledge with internal/external peers (i.e. Metadata mappings); and iii) governance interoperability with semantic resources supporting the assurance and control of collaboration with internal/external peers exchanging data, information, and knowledge cross legal jurisdictions (i.e. Sematic Interoperability Agreements). Interoperability Dimension: Structural IoP Viewpoint: Highlevel viewpoint Additional identifier: http://data.europa.eu/dr8/SharedKnowledgeContentGrouping EIF Layer: Semantic Definition: Digital Solution Scalability Architecture Decision Catalogue ABB is a grouping that covers a range of Architecture Decision Records (ADRs) that are designed to ensure that a system can effectively scale to handle increased workload or user demands. This includes decisions related to horizontal scaling, database sharding, elastic cloud infrastructure, containerization and orchestration, vertical scaling, load balancing strategy, and scalability for growth. Source: EIRA Team Research Additional information: The Digital Solution Scalability Architecture Decision Catalogue ABB is a comprehensive collection of ADRs that address various aspects of system scalability. 'Horizontal Scaling' refers to the ability to increase capacity by connecting multiple hardware or software entities to work as a single logical unit. 'Database Sharding' is a type of database partitioning that separates very large databases into smaller, faster, more easily managed parts called data shards. 'Elastic Cloud Infrastructure' refers to the provision of IT infrastructure through the internet on an on-demand, pay-per-use basis. 'Containerization and Orchestration' involves encapsulating or packaging up software code and all its dependencies so that it can run uniformly and consistently on any infrastructure. 'Vertical Scaling' involves adding more resources such as computing power or memory to a server, or replacing one server with a more powerful one. 'Load Balancing Strategy' involves distributing network traffic across multiple servers to ensure no single server becomes overwhelmed with traffic. 'Scalability for Growth' involves designing the system in such a way that it can handle increased workload or user demands in the future. Example: For instance, a company might decide to adopt a horizontal scaling strategy to handle increased user demands during peak times. This might involve adding more servers to their system to distribute the load more evenly. Similarly, a company with a large, complex database might decide to implement database sharding to improve performance and make the database more manageable. On the other hand, a company expecting rapid growth might decide to adopt an elastic cloud infrastructure to easily scale up or down based on demand. LOST view: Digital Solution Architecture Decisions Catalogue view Identifier: http://data.europa.eu/dr8/egovera/DigitalSolutionScalabilityArchitectureDecisionCatalogueGrouping ABB name: egovera:DigitalSolutionScalabilityArchitectureDecisionCatalogueGrouping EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-08-18 dct:identifier: http://data.europa.eu/dr8/egovera/DigitalSolutionScalabilityArchitectureDecisionCatalogueGrouping dct:title: Digital Solution Scalability Architecture Decision Catalogue Catalogue Definition: Digital Solution Security, Privacy and Compliance Architecture Decision Catalogue ABB is a grouping that covers a range of elements focused on security-related decisions made during the architectural design process. These elements document choices related to authentication mechanisms, encryption methods, access control, and other security considerations. Source: EIRA Team Research Additional information: The catalogue includes elements such as 'Authentication Mechanism', 'Encryption Standards', 'Secure Communications', 'Role-Based Access Control', 'Security Testing', 'Security Incident Response', 'Access Control Policy', 'Continuous Security Monitoring', 'Retention and Data Deletion', 'Security Incident Response Plan', 'Compliance Monitoring and Auditing', and 'Data Protection Measures'. Each of these elements represents a specific decision made in the architectural design process, with a focus on ensuring the security, privacy, and compliance of the digital solution. The decisions made in these areas can have significant impacts on the overall security posture of the solution, and as such, they are carefully documented and monitored. Example: Authentication Mechanism This could involve a decision to use multi-factor authentication for all user logins, to enhance the security of the system. Encryption Standards This might involve a decision to use a specific encryption standard, such as AES-256, for all data at rest and in transit. Secure Communications This could involve a decision to use secure communication protocols, such as HTTPS and SSL/TLS, to protect data during transmission. Role-Based Access Control This might involve a decision to implement role-based access control, to ensure that users only have access to the data and functions that they need for their role. LOST view: Digital Solution Architecture Decisions Catalogue view Identifier: http://data.europa.eu/dr8/egovera/DigitalSolutionSecurityPrivacyAndComplianceArchitectureDecisionCatalogueGrouping ABB name: egovera:DigitalSolutionSecurityPrivacyAndComplianceArchitectureDecisionCatalogueGrouping EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-08-18 dct:identifier: http://data.europa.eu/dr8/egovera/DigitalSolutionSecurityPrivacyAndComplianceArchitectureDecisionCatalogueGrouping dct:title: Digital Solution Security, Privacy And Compliance Architecture Decision Catalogue Catalogue Definition: Data Space Enablers ABB is a Grouping that refers to components and services that support the creation and management of a dataspace. Source: Inspired in IDSA Source reference: https://internationaldataspaces.org/why/data-spaces/ Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/DataspaceEnablersGrouping LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:DataspaceEnablersGrouping Interoperability Saliency: The Data Spaces Enablers Grouping ABB is salient for technical interoperability because it comprises the core elements, components, and services required to set up Data Spaces that are interoperable between them. Data Spaces can be part of the environment for the implementation and delivery of interoperable digital public services. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/DataspaceEnablersGrouping EIF Layer: TechnicalApplication Definition: Test Enablers ABB is a Grouping that refers to the applications and services that support the development and deployment of conformance testing and validation. Source: Inspired in European Comision Source reference: https://digital-strategy.ec.europa.eu/en/faqs/testing-and-experimentation-facilities-tefs-questions-and-answers Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/TestEnablersGrouping LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:TestEnablersGrouping Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Interoperability Testbed - The Test Bed allows users to execute predefined test cases on their systems in order to test the conformance to standards and requirements, simulate a web-service, validate content and test a complete message exchange protocol. The Testbed manages test cases and users, and orchestrates domain-specific components, the domain-specific logic is in separate components that are used via web services. Test results are provided in a standardised, machine-readable format. The Test Bed also offers a test registry and repository (TRR) to store test artefacts (assertions, test cases, validation schemas, etc.) and compile test services (validation services, simulator services, etc.). Please visit the following website for more information: https://ec.europa.eu/isa2/solutions/interoperability-test-bed_en Interoperability Saliency: The Test Enablers Grouping ABB is salient for interoperability because testing and validation solutions services are relevant aspects to ensure that they are conformant to relevant standards enabling interoperability. Interoperability Dimension: Governance IoP Additional identifier: http://data.europa.eu/dr8/TestEnablersGrouping EIF Layer: TechnicalApplication Definition: Digital Solution Portability and Scalability Architecture Decision Catalogue ABB is a grouping that covers a range of technical architectural decisions related to the portability and scalability of digital solutions. These decisions are documented in the form of Architecture Decision Records (ADRs) and typically involve choosing specific technologies, frameworks, protocols, or design patterns to ensure the solution's adaptability, installability, replaceability, and its ability to manage and exchange data across borders. Source: EIRA Team Research Additional information: The catalogue includes decisions about Semantic Capability, Cross-Border Semantic Data Management, Cross-Border Data Exchange, Data Exchange Deployment, Data Exchanger Operations, Adaptability, Installability, and Replaceability. Each decision record provides a detailed description of the decision, the context in which it was made, the factors considered, and the implications of the decision. These decisions are crucial for ensuring that the digital solution can be easily installed, replaced, and adapted to changing requirements, and that it can effectively manage and exchange data across borders. Example: For instance, the 'Semantic Capability' decision might involve choosing a specific semantic technology to ensure that the digital solution can understand and interpret the meaning of the data it processes. The 'Cross-Border Data Exchange' decision might involve selecting a specific data exchange protocol to ensure that the solution can effectively exchange data with systems in other countries. The 'Adaptability' decision might involve choosing a modular design pattern to ensure that the solution can be easily adapted to changing requirements. LOST view: Digital Solution Architecture Decisions Catalogue view Identifier: http://data.europa.eu/dr8/egovera/DigitalSolutionPortabilityAndScalabilityArchitectureDecisionCatalogueGrouping ABB name: egovera:DigitalSolutionPortabilityAndScalabilityArchitectureDecisionCatalogueGrouping EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-08-18 dct:identifier: http://data.europa.eu/dr8/egovera/DigitalSolutionPortabilityAndScalabilityArchitectureDecisionCatalogueGrouping dct:title: Digital Solution Portability And Scalability Architecture Decision Catalogue Catalogue Definition: Application Integration Infrastructure Enablers ABB is a Grouping that refers to the set of components and services facilitating the integration of disparate applications and systems within an organization Source: Inspired in European Alliance for Industrial Data, Edge and Cloud Source reference: https://digital-strategy.ec.europa.eu/en/policies/cloud-alliance Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/ApplicationIntegrationInfrastructureEnablersGrouping LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:ApplicationIntegrationInfrastructureEnablersGrouping Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): API Manager, WSO2 API Manager is a complete platform for building, integrating, and exposing your digital services as managed APIs in the cloud, on-premise, and hybrid architectures to drive your digital transformation strategy. https://apim.docs.wso2.com/en/latest/ Interoperability Saliency: Application Integration Infrastructure Enablers ABB is salient for semantic and technical interoperability because it provides mechanisms and assets to expose open APIs regarding public services that permit machines to discover and understand available public services. Also, this ABB facilitates data consumption and sharing through these public services exposed. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/ApplicationIntegrationInfrastructureEnablersGrouping EIF Layer: TechnicalInfrastructure Definition: European Data Sharing Principles Catalogue (EDSPC) is a grouping that covers a range of principles related to data sharing within the European context. These principles include Self Determination, Inclusion, Fundamental Rights, Consumer Protection, Fair Competition, Citizen Participation, Sustainability, and Data Altruism. Each principle represents a key aspect of data sharing and management in Europe, reflecting the region's commitment to privacy, inclusivity, and sustainability. Source: EIRA Team Research Additional information: The European Data Sharing Principles Catalogue is a comprehensive list of principles that guide data sharing practices in Europe. 'Self Determination' refers to the ability of individuals or organizations to control their own data. 'Inclusion' ensures that all individuals and organizations have equal access to data resources. 'Fundamental Rights' protect the basic rights of individuals in relation to data, such as privacy and freedom of expression. 'Consumer Protection' safeguards consumers from harmful data practices. 'Fair Competition' promotes a level playing field in the data market. 'Citizen Participation' encourages public involvement in data-related decisions. 'Sustainability' emphasizes the long-term viability of data practices. Finally, 'Data Altruism' encourages the voluntary sharing of data for the common good. Example: An example of the application of these principles can be seen in the European Union's General Data Protection Regulation (GDPR). This regulation embodies principles such as Self Determination, Fundamental Rights, and Consumer Protection by giving individuals control over their personal data and protecting them from harmful data practices. Similarly, initiatives that promote open data or data philanthropy reflect the principles of Inclusion, Citizen Participation, and Data Altruism. LOST view: Architecture Principles view Identifier: http://data.europa.eu/dr8/egovera/EuropeanDataSharingPrinciplesCatalogueGrouping ABB name: egovera:EuropeanDataSharingPrinciplesCatalogueGrouping EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-08-18 dct:identifier: http://data.europa.eu/dr8/egovera/EuropeanDataSharingPrinciplesCatalogueGrouping dct:title: European Data Sharing Principles Catalogue Catalogue Definition: Scalability Requirements Catalogue ABB is a grouping that covers a range of non-functional IT requirements that are critical for ensuring the scalability, performance, and efficiency of a system or application. It includes elements such as Traffic Pattern, Elasticity, and Latency, each of which plays a key role in determining how well a system can handle user traffic and respond to changes in demand. Source: EIRA Team Research Additional information: The Scalability Requirements Catalogue ABB is a comprehensive collection of non-functional requirements that are essential for the design and operation of scalable IT systems. The 'Traffic Pattern' element refers to the expected volume and frequency of user traffic, which helps in planning the necessary infrastructure and resources. 'Elasticity' refers to the system's ability to scale up or down based on demand, ensuring optimal performance and cost-efficiency. 'Latency', on the other hand, refers to the time delay between a request and response, which is a crucial factor in the overall user experience. By considering these elements, IT professionals can design systems that are robust, scalable, and efficient, meeting the needs of users while optimizing resource utilization. Example: For instance, a video streaming service needs to consider all these elements in their system design. The 'Traffic Pattern' would help them prepare for peak viewing times and ensure the system can handle the load. 'Elasticity' would allow the service to scale up during popular live events and scale down during off-peak hours, optimizing resource use. Lastly, 'Latency' is critical for providing a smooth viewing experience, as high latency could lead to buffering and lagging issues. LOST view: Digital Solution Non-Functional Requirements Catalogue view Identifier: http://data.europa.eu/dr8/egovera/ScalabilityRequirementsCatalogueGrouping ABB name: egovera:ScalabilityRequirementsCatalogueGrouping EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-08-17 dct:identifier: http://data.europa.eu/dr8/egovera/ScalabilityRequirementsCatalogueGrouping dct:title: Scalability Requirements Catalogue Catalogue Definition: Technical Governance Content ABB is a Grouping that refers to formal decisions on technical frameworks, institutional arrangements, organisational structures, roles and responsibilities, policies, agreements and other aspects of ensuring and monitoring public services at national and EU levels Source: Inspired in EIF Source reference: https://ec.europa.eu/isa2/sites/default/files/eif_brochure_final.pdf Identifier: http://data.europa.eu/dr8/TechnicalGovernanceContentGrouping eira:ID: http://data.europa.eu/dr8/TechnicalGovernanceContentGrouping ABB name: eira:TechnicalGovernanceContentGrouping Definition: Durability Requirements Catalogue ABB is a grouping that covers a set of non-functional IT requirements that ensure the long-term reliability, stability, and accessibility of a system. These requirements include replication, fault tolerance, and archivability, each of which plays a crucial role in maintaining the system's performance, security, and data integrity over time. Source: EIRA Team Research Additional information: The Durability Requirements Catalogue ABB is a comprehensive collection of non-functional requirements that are essential for the long-term operation of a system. 'Replication' refers to the system's ability to duplicate data or processes across multiple servers or locations, ensuring high availability and reliability. 'Fault tolerance' is the system's ability to continue functioning despite hardware or software failures, involving redundancy, backup systems, and failover mechanisms. 'Archivability' refers to the system's ability to store and retrieve data over a long period of time, ensuring that the data remains accurate, complete, and secure. Each of these elements is critical for systems that handle sensitive or critical data, such as those used in healthcare, finance, and transportation. Example: An example of the application of the Durability Requirements Catalogue ABB could be a healthcare system. The system would need to replicate patient data across multiple servers to ensure it is always available when needed. It would also need to be fault-tolerant, so that in the event of a hardware or software failure, the system could continue to function without disruption. Lastly, the system would need to be archivable, storing patient data securely and in a retrievable format for many years, in compliance with regulatory requirements. LOST view: Digital Solution Non-Functional Requirements Catalogue view Identifier: http://data.europa.eu/dr8/egovera/DurabilityRequirementsCatalogueGrouping ABB name: egovera:DurabilityRequirementsCatalogueGrouping EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-08-17 dct:identifier: http://data.europa.eu/dr8/egovera/DurabilityRequirementsCatalogueGrouping dct:title: Durability Requirements Catalogue Catalogue Definition: Availability Requirements Catalogue ABB is a grouping that covers a range of non-functional requirements that are critical for the operation, maintenance, and usability of a system. This includes elements such as 'Deployment Stamps' and 'Geodes', which refer to the need for a system to have a timestamp or version number associated with each deployment, and the ability of a system to accurately determine the location of a user or device, respectively. Source: EIRA Team Research Additional information: The Availability Requirements Catalogue ABB is a comprehensive collection of non-functional requirements that are essential for the effective operation and maintenance of a system. 'Deployment Stamps' are crucial for tracking and identifying different versions of the system, enabling easy rollback to a previous version if necessary, and ensuring system stability and reliability. 'Geodes', on the other hand, refers to the system's ability to accurately pinpoint the location of a user or device, which is critical for systems that rely on location-based services. The accuracy and reliability of geodes can significantly impact the functionality and usability of the system, and in certain applications, can have serious consequences. Example: Examples of application for the elements in the Availability Requirements Catalogue ABB include software development projects where 'Deployment Stamps' would be used to track different versions of the software, and navigation or emergency response systems where 'Geodes' would be used to provide precise location data. LOST view: Digital Solution Non-Functional Requirements Catalogue view Identifier: http://data.europa.eu/dr8/egovera/AvailabilityRequirementsCatalogueGrouping ABB name: egovera:AvailabilityRequirementsCatalogueGrouping EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-08-17 dct:identifier: http://data.europa.eu/dr8/egovera/AvailabilityRequirementsCatalogueGrouping dct:title: Availability Requirements Catalogue Catalogue Definition: Shared Organisational Content ABB is a Grouping setting organizational (re)usable resources with convergence power, to public policy goals attainment, enabling to reuse and share digital assets, knowledge repositories, best practices, and expertise across departments and agencies. This facilitates seamless collaboration, enhances efficiency, and fosters innovation in the development and delivery of Digital Public Services, aligning with the overarching goal of improving citizen experiences and outcomes. Source: EUR-LEX Source reference: (https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32021R0695&qid=1646736486403) Last modification: 2023-11-20 Identifier: http://data.europa.eu/dr8/SharedOrganisationalContentGrouping LOST view: Organisational view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:SharedOrganisationalContentGrouping Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): The recent economic and financial crisis revealed weaknesses in the EU's economic governance. The EU responded by taking a wide range of measures to strengthen its governance and to facilitate a return to sustainable economic growth, job creation, financial stability and sound public finances.(https://ec.europa.eu/info/sites/default/files/eu-economic-governance-explained.pdf) Interoperability Saliency: The Shared Organisational Content ABB is a key interoperability enabler (*) for the governance, behavioural and structural enablers. This ABB is salient for legal interoperability because it defines the public policy goals that enable enabling i) sharing/provisioning/reusing/consumption of understandings and agreements on digital public services, ii) the exchange of data, information, and knowledge between digital public services, and iii) collaboration between digital public services Additional information: This convergence power is based on the enabling communication and harmonization nature of these resources influencing collaboration cross levels in a public administration, cross public administrations, and cross borders. The degree of achievement could range from an ideal perfect shared governance framework (i.e. no interoperability barriers from the organisational perspective) to an imperfect or even null shared governance framework (i.e. some interoperability barriers from the organizational perspective). The level of organizational interoperability will constrain digital public services cross levels in a public administration, cross public administrations, and cross borders. The shared governance framework enables: i) structural interoperability with organisational resources supporting reusing and/or sharing of digital public services (i.e. public services catalogues); ii) behavioural interoperability with organisational resources supporting exchanging capabilities of data, information or knowledge with internal/external peers (i.e. user experience patterns and service delivery mode); and iii) governance interoperability with governance resources supporting the assurance and control of collaboration with internal/external peers exchanging data, information, and knowledge (i.e. Organisational Interoperability Agreements). Interoperability Dimension: Structural IoP Viewpoint: Highlevel viewpoint Additional identifier: http://data.europa.eu/dr8/SharedOrganisationalContentGrouping EIF Layer: Organisational Definition: Artificial Intelligence Infrastructure Enablers ABB is a Grouping that refers to a set of components that facilitate the development and deployment of artificial intelligence applications Source: European Comission Source reference: https://digital-strategy.ec.europa.eu/en/library/definition-artificial-intelligence-main-capabilities-and-scientific-disciplines Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/ArtificialIntelligenceInfrastructureEnablersGrouping LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:ArtificialIntelligenceInfrastructureEnablersGrouping Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): AI Whatch Artificial Intelligence in public administrations. https://publications.jrc.ec.europa.eu/repository/bitstream/JRC120399/jrc120399_misuraca-ai-watch_public-services_30062020_def.pdf Interoperability Saliency: Artificial Intelligence Infrastructure Enablers ABB is salient for semantic interoperability because it refers to the generation of newer insights (knowledge) from public data to generate (i) new curated datasets and/or (ii) new public data assets based on the combination of other public data. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/ArtificialIntelligenceInfrastructureEnablersGrouping EIF Layer: TechnicalInfrastructure The [Solution design of a target digital public service] is a view that defines the technological architecture of the service. It outlines the components of the service, how they will be integrated, and how they will communicate with each other. The solution design also includes a description of the service user interface (UI) and a plan for testing and deployment. A documentation of an existing digital public service is a similar document, but it focuses on the current state of the service. It includes a description of the service's functionality, the technical infrastructure that supports it, and the processes that are involved in delivering the service. Both types of documents are important for ensuring that digital public services are interoperable, which means that they can exchange data and work together seamlessly. The European Interoperability Reference Architecture (EIRA) is a set of guidelines that can be used to develop interoperable digital public services. Definition: The description contains a full description of the architectural decisions. Source: EIRA Team Research Additional information: The Digital Solution Business Architecture Decision Catalogue ABB is a structured collection of architectural decisions made for digital business solutions. Each element in the catalogue represents a specific decision, such as 'Cross-Border Identification Business' or 'Data Subscription Capability'. These decisions are recorded in an Architecture Decision Record (ADR), which provides a detailed description of the decision, the context in which it was made, the contributing factors, and the consequences. The catalogue serves as a reference for understanding the architectural design of the digital solution and can be used to guide future decision-making. LOST view: Digital Solution Architecture Decisions Catalogue view Identifier: http://data.europa.eu/dr8/egovera/DigitalSolutionBusinessArchitectureDecisionCatalogueGrouping ABB name: egovera:DigitalSolutionBusinessArchitectureDecisionCatalogueGrouping EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-08-18 dct:identifier: http://data.europa.eu/dr8/egovera/DigitalSolutionBusinessArchitectureDecisionCatalogueGrouping dct:title: Digital Solution Business Architecture Decision Catalogue Catalogue Definition: Schedule Management Enablers ABB is a Grouping that enables the implementation of components and services to create, distribute and manage events at different scales inside a cloud platform. Source: Inspired in Redhat Source reference: https://www.redhat.com/en/topics/cloud-computing/what-is-cloud-management Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/ScheduleManagementEnablersGrouping LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:ScheduleManagementEnablersGrouping Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Chronos is a replacement for cron. It is a distributed and fault-tolerant scheduler that runs on top of Apache Mesos that can be used for job orchestration. It supports custom Mesos executors as well as the default command executor. Thus by default, Chronos executes sh (on most systems bash) scripts. https://sourceforge.net/projects/chronos.mirror/ Interoperability Saliency: The Schedule Management Enablers Grouping ABB is salient for technical interoperability because it comprises the different services and tools that allow to organise and manage events within a platform for the delivery of a digital public service. It enables interoperability by allowing the management of events through a single point of access (for users and administrations) and the reuse of such information to an overall relationship between public administration and stakeholders. Additional identifier: http://data.europa.eu/dr8/ScheduleManagementEnablersGrouping EIF Layer: TechnicalApplication Interoperability Dimension: Structural IoP Definition: Enterprise Architecture Framework (EAF) alignment guidelines ABB is a Grouping that covers the process of establishing a harmonious relationship between the European Interoperability Reference Architecture (EIRA) model and any given Enterprise Architecture Framework (EAF). The aim is to make the EIRA model fully compliant with the chosen EAF, promoting uniformity across the architectural ecosystem. Source: EIRA Team Research Additional information: The EAF alignment guidelines serve as an integral part of the process, aiming to establish a harmonious relationship between the European Interoperability Reference Architecture (EIRA) model and any given Enterprise Architecture Framework (EAF). The ultimate goal is to make the EIRA model fully compliant with the chosen EAF, promoting uniformity across the architectural ecosystem. The elements contained within these guidelines include Interoperable European Solution, Achieve Interoperability, Creation of Interoperable European Solutions, European Interoperability Reference Architecture, Coordination Capacity, Regulatory Capacity, Delivery Capacity, Analytical Capacity, EIRA Ontology, Public Administration, Architecture Principle, Constraints, Assumptions and Decisions, Shared Legal Content, Shared Organisational Content, Digital Solution Requirement, Iternational Data Spaces Reference Architecture Model (IDS-RAM), Data Spaces Business Alliance, Eclipse Dataspace Components, JRC Data Spaces Knowledge Base, FIWARE for Data Spaces, Gaia-X Data Spaces Community. Example: An example of the application of the EAF alignment guidelines could be the process of aligning a national public administration's enterprise architecture with the EIRA model. This would involve assessing the current architecture, identifying gaps and areas of non-compliance, and implementing changes to achieve alignment. The guidelines would provide a roadmap for this process, outlining the necessary steps and considerations. LOST view: Enterprise Architecture Framework alignment guidelines view Identifier: http://data.europa.eu/dr8/egovera/EnterpriseArchitectureFrameworkAlignmentGuidelinesGrouping ABB name: egovera:EnterpriseArchitectureFrameworkAlignmentGuidelinesGrouping EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-08-20 dct:identifier: http://data.europa.eu/dr8/egovera/EnterpriseArchitectureFrameworkAlignmentGuidelinesGrouping dct:title: Enterprise Architecture Framework (EAF) Alignment Guidelines Catalogue Definition: Digital Solution Usability Architecture Decision Catalogue (DSUADC) is a grouping that covers a collection of architectural decision records (ADRs) that focus on the usability aspects of a digital solution's architecture. These decisions involve considerations about adequacy recognition, learning, operability, user interface, and accessibility. Source: EIRA Team Research Additional information: The DSUADC is a comprehensive catalogue that documents crucial decisions made about the usability aspects of a digital solution's architecture. Each element in the catalogue represents a specific area of focus. 'Adequacy Recognition' refers to decisions about how well the solution meets user needs and expectations. 'Learning' covers decisions about how users learn to use the solution. 'Operability' involves decisions about the ease of operating the solution. 'User Interface' refers to decisions about the design and functionality of the user interface. 'Accessibility' covers decisions about making the solution accessible to all users, including those with disabilities. Example: For instance, an ADR under 'Adequacy Recognition' might document the decision to use a particular user feedback system to ensure the solution meets user needs. An ADR under 'Learning' might cover the decision to include interactive tutorials to help new users learn how to use the solution. An ADR under 'Operability' might document the decision to use a specific technology to ensure smooth operation of the solution. An ADR under 'User Interface' could cover the decision to use a specific design pattern for the user interface. Lastly, an ADR under 'Accessibility' might document the decision to follow specific accessibility standards to make the solution usable by people with disabilities. LOST view: Digital Solution Architecture Decisions Catalogue view Identifier: http://data.europa.eu/dr8/egovera/DigitalSolutionUsabilityArchitectureDecisionCatalogueGrouping ABB name: egovera:DigitalSolutionUsabilityArchitectureDecisionCatalogueGrouping EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-08-18 dct:identifier: http://data.europa.eu/dr8/egovera/DigitalSolutionUsabilityArchitectureDecisionCatalogueGrouping dct:title: Digital Solution Usability Architecture Decision Catalogue Catalogue Definition: Semantic Governance Content ABB is a Grouping that refers to the concepts and terms to support the elaboration of rules and mechanims to enhance the availability, integrity, interoperability and security of data while respecting data protection and ethical rules Source: EUR-LEX Source reference: https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:52020PC0767 Identifier: http://data.europa.eu/dr8/SemanticGovernanceContentGrouping eira:ID: http://data.europa.eu/dr8/SemanticGovernanceContentGrouping ABB name: eira:SemanticGovernanceContentGrouping Definition: Blockchain Infrastructure Enablers ABB is a Grouping of a set of components and services that permit building a digital ledger infrastructure of interconnected nodes to facilitate a trustworthy environment to share data. Source: European Comission Source reference: https://digital-strategy.ec.europa.eu/en/policies/european-blockchain-services-infrastructure Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/BlockchainInfrastructureEnablersGrouping LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:BlockchainInfrastructureEnablersGrouping Synonym: Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): OpenCHAIN is an open-source blockchain platform with distributed ledger technology. This blockchain company is suitable for organizations managing digital assets in secure and robust ways. Blockchain technology does not require fees for mining and the Bitcoin blockchain is significant for its immutability. https://www.openchainproject.org/ Interoperability Saliency: Blockchain Infrastructure Enablers ABB is salient for organizational interoperability due to it setting up the rules for generating a trustworthy network that permits (i) sharing information related to public services securely and privately, and (ii) ensuring the public information is consistent in time. Additional information: Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/BlockchainInfrastructureEnablersGrouping EIF Layer: TechnicalInfrastructure Definition: Shared Application Content ABB is a Grouping setting application (re)usable resources, with convergence power, in relation to public policy goals attainment, enabling to reuse and share software tools and services, fostering collaborative functionality within and across applications to support the attainment of public policy goals and the creation of interoperable digital public services. Source: Inspired in referent cloud service providers definitions Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): Technical Specification for Interoperability (TSI), a technical and operational standard which must be met by each subsystem or part of subsystem in order to meet the essential requirements and ensure the interoperability of the railway system of the European Union. Directive (EU) 2016/797 defines the subsystems, either structural or functional, forming part of the railway system of the European Union. For each of those subsystems, the essential requirements need to be specified and the technical specifications determined, particularly in respect of constituents and interfaces, in order to meet those essential requirements. The essential requirements can be summarised as safety, reliability and availability, health, environmental protection, technical compatibility and accessibility. (https://eur-lex.europa.eu/legal-content/EN/TXT/?qid=1519999459620&uri=CELEX:32016L0797) Last modification: 2024-01-08 Identifier: http://data.europa.eu/dr8/SharedApplicationContentGrouping LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:SharedApplicationContentGrouping Interoperability Saliency: The Shared Application Content ABB is a key interoperability enabler (*) for governance, behavioural and structural interoperability. This ABB is salient for application interoperability with public policy goals convergence value by enabling i) the provision/consumption of data by public services, ii) the exchange of data, information, and knowledge between digital public services, and iii) collaboration between digital public services. Interoperability Dimension: Governance IoP Viewpoint: Highlevel viewpoint Additional identifier: http://data.europa.eu/dr8/SharedApplicationContentGrouping EIF Layer: TechnicalApplication Definition: Digital Public Service Strategy (Public Policy Cycle) Principle Catalogue ABB is a grouping that covers a range of principles and strategies related to the implementation and management of digital public services. These principles include accessibility, accountability, best fit public service implementation orientation, care from cradle to grave, data sovereignty, deployment fit (Cloud-first approach), digital first, digital partnership, digital sovereignty and autonomy, evidence-based public policy, social participation, transparency of internal information systems, and transparency of the administrative environment. Source: EIRA Team Research Additional information: The catalogue is a comprehensive collection of principles and strategies that guide the implementation, management, and evolution of digital public services. 'Accessibility' ensures services are available to all citizens, 'Accountability' ensures responsible use of resources and power, 'Best fit Public Service Implementation Orientation' guides the implementation process, 'Care from cradle to grave' ensures lifelong support for citizens, 'Data Sovereignty' ensures citizens' data rights, 'Deployment fit (Cloud-first approach)' guides the deployment of services, 'Digital First' prioritizes digital solutions, 'Digital Partnership' encourages collaboration, 'Digital sovereignty and autonomy' ensures digital independence, 'Evidence based Public Policy' ensures policies are based on factual data, 'Social participation' encourages citizen involvement, 'Transparency of internal information systems' ensures openness about system operations, and 'Transparency of the administrative environment' ensures openness about administrative processes. Example: An example of 'Accessibility' could be a government website that is designed to be user-friendly for all citizens, including those with disabilities. An example of 'Accountability' could be a public service agency that regularly publishes reports on its spending and activities. An example of 'Best fit Public Service Implementation Orientation' could be a government agency that carefully selects the most suitable software for its needs, rather than simply choosing the most popular or cheapest option. An example of 'Care from cradle to grave' could be a government health service that provides care for citizens from birth to old age. LOST view: Architecture Principles view Identifier: http://data.europa.eu/dr8/egovera/DigitalPublicServiceStrategyPrincipleCatalogueGrouping ABB name: egovera:DigitalPublicServiceStrategyPrincipleCatalogueGrouping EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-08-20 dct:identifier: http://data.europa.eu/dr8/egovera/DigitalPublicServiceStrategyPrincipleCatalogueGrouping dct:title: Digital Public Service Strategy (Public Policy Cycle) Principle Catalogue Catalogue Definition: Identification and Access Enablers ABB is a Grouping that refers to components to enable the secure identification and authentication of users, systems and services into a platform. Source: World Bank Source reference: https://id4d.worldbank.org/guide/enablers Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/IdentificationAndAccessEnablersGrouping LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:IdentificationAndAccessEnablersGrouping Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): EU Login - EU Login is the European Commission's user authentication service. It allows authorised users to access a wide range of Commission web services. EU Login is the entry gate to sign in to different European Commission services and/or other systems. EU Login verifies your identity and allows recovering your personal settings, history and access rights in a secure way. You can sign in using social media accounts or the EU Login account. EU Login supports a variety of verification methods: • Password; • ECAS Mobile App PIN code; • ECAS Mobile App QR code; • On mobile authentication; • Mobile phone + SMS; • Token and Token CRAM. https://webgate.ec.europa.eu/cas/about.html Interoperability Saliency: The Identification and Access Enablers Grouping ABB is salient for interoperability because it is composed of the different tools, mechanisms and platforms that can ensure the access rights, and the confidentiality of data. In general terms, identification and authentication are relevant aspects that can enable trustworthy data exchanges or harm data in interoperable digital services. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/IdentificationAndAccessEnablersGrouping EIF Layer: TechnicalApplication Definition: Containers Infrastructure Enabler ABB is a Grouping of components and services enabling a virtual packaging code and isolated applications for deployment of public services. Source: Inspired in referent cloud service providers Source reference: Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/ContainersInfrastructureEnablersGrouping LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:ContainersInfrastructureEnablersGrouping Synonym: Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): OpenSHIFT is a secure and an enterprise-grade cloud-based container orchestration system with Kubernetes at the backend. It can be used both as a Red Hat Container Orchestration Engine and Platform-as-a-Service (PaaS). https://github.com/openshift/origin Interoperability Saliency: Containers Infrastructure Enablers ABB is salient for organizational interoperability due to setting up the rules and business process to establish and manage the virtual tools that permit determining the functionality of the public digital services. Additional information: Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/ContainersInfrastructureEnablersGrouping EIF Layer: TechnicalInfrastructure Definition: Digital Solution Technical Architecture Decision Catalogue ABB is a Grouping that covers a range of elements related to the technical architectural decisions made during the development of a software system. These decisions typically involve the selection of specific technologies, frameworks, protocols, or design patterns that are best suited to the system's requirements and objectives. Source: EIRA Team Research Additional information: The catalogue includes elements such as 'Technology Stack Selection', 'API Design', 'Event-Driven Architecture', 'Database Schema Design', 'Asynchronous Processing', 'Provide a Service Catalog', 'Managing Self-Description Schemas in the Federated Catalogue', 'Monolithic Architecture', 'Microservice Architecture', 'Serveless Architecture', 'Cloud-Native Architecture', 'Big-Data Architecture', and 'Service-Oriented Architecture'. Each of these elements represents a specific architectural decision that needs to be made during the development of a software system. These decisions are critical as they determine the overall structure and functionality of the system, as well as its ability to meet the needs of its users and to adapt to changes in technology and business requirements. Example: For instance, the 'Technology Stack Selection' element involves deciding on the specific technologies to be used in the system, such as the programming languages, databases, server technologies, and other tools. The 'API Design' element involves deciding on the structure and functionality of the APIs that the system will provide, which can affect its interoperability with other systems. The 'Event-Driven Architecture' element involves deciding on the use of events to drive the system's behavior, which can affect its responsiveness and scalability. LOST view: Digital Solution Architecture Decisions Catalogue view Identifier: http://data.europa.eu/dr8/egovera/DigitalSolutionTechnicalArchitectureDecisionCatalogueGrouping ABB name: egovera:DigitalSolutionTechnicalArchitectureDecisionCatalogueGrouping EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-08-18 dct:identifier: http://data.europa.eu/dr8/egovera/DigitalSolutionTechnicalArchitectureDecisionCatalogueGrouping dct:title: Digital Solution Technical Architecture Decision Catalogue Catalogue Definition: Problem Statement Grouping refers to the set of elements needed for the detailed description of the issues, goals, constraints, and context influencing the creation and implementation of digital public services. It includes defining strategic goals, identifying regulatory and technical constraints, ensuring alignment with public policy objectives, providing guidelines for service implementation, understanding the context of policy decisions, and recognizing technical barriers and underlying assumptions. This problem statement serves as a framework to address interoperability challenges in digital public services, aligning solutions with public policy goals and relevant constraints. Source: EIRA Team Last modification: 2024-05-23 Identifier: http://data.europa.eu/dr8/ProblemStatementGrouping LOST view: EIRA Ontology view Additional identifier: http://data.europa.eu/dr8/ProblemStatementGrouping ABB name: eira:ProblemStatementGrouping Definition: Binding power ABB is a Requirement that to the legal authority or force of a law or decision that requires compliance by those who are subject to it. Source: Inspired in ILO Source reference: https://www.ilo.org/global/topics/labour-migration/publications/WCMS_385582/lang--en/index.htm Definition: Digital Solution High Availability and Resilience Architecture Decision Catalogue ABB is a grouping that covers a range of decisions related to optimizing the performance of a system. These decisions may include choices regarding caching strategies, load balancing techniques, database optimizations, or any other performance-related considerations. The catalogue includes elements such as Caching Strategy, Content Delivery Network, Performance Testing and Tuning, Network Optimization, Application of Service Monitoring Tools, Application of Service Monitoring Tools Configuration, and Disaster Recovery Plan. Source: EIRA Team Research Additional information: The Digital Solution High Availability and Resilience Architecture Decision Catalogue ABB is a comprehensive collection of elements that capture decisions related to optimizing the performance of a system. Each element in the catalogue represents a specific decision area, with a focus on strategies and techniques that can enhance system performance, ensure high availability, and build resilience. The elements are described in the form of Architecture Decision Records (ADRs), which provide a detailed account of the decision-making process, the options considered, the decision taken, and the reasons behind the decision. Example: For instance, the 'Caching Strategy' element in the catalogue might detail the decision to use a distributed caching system to improve the performance of a data-intensive application. The 'Content Delivery Network' element might describe the decision to use a global CDN to ensure fast and reliable content delivery to users worldwide. The 'Performance Testing and Tuning' element might outline the decision to implement a rigorous performance testing regime and a continuous tuning process to maintain optimal system performance. Similarly, the 'Network Optimization', 'Application of Service Monitoring Tools', 'Application of Service Monitoring Tools Configuration', and 'Disaster Recovery Plan' elements would detail decisions in their respective areas. LOST view: Digital Solution Architecture Decisions Catalogue view Identifier: http://data.europa.eu/dr8/egovera/DigitalSolutionHighAvailabilityAndResilienceArchitectureDecisionCatalogueGrouping ABB name: egovera:DigitalSolutionHighAvailabilityAndResilienceArchitectureDecisionCatalogueGrouping EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-08-18 dct:identifier: http://data.europa.eu/dr8/egovera/DigitalSolutionHighAvailabilityAndResilienceArchitectureDecisionCatalogueGrouping dct:title: Digital Solution High Availability And Resilience Architecture Decision Catalogue Catalogue Definition: Workflow Orchestration Infrastructure Enablers ABB is a Grouping that refers to components and services that enable the coordination and automation of components through workflows across multiple systems, applications, and organizations. Source: Inspired in Redhat Source reference: https://www.redhat.com/en/topics/automation/what-is-orchestration Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/WorkflowOrchestrationInfrastructureEnablersGrouping LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:WorkflowOrchestrationInfrastructureEnablersGrouping Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): UNDP- Business Process Re-engineering Manual. https://www.undp.org/sites/g/files/zskgke326/files/migration/uz/BPR-Manual_designed---Eng---final.pdf Interoperability Saliency: Process Orchestration Infrastructure Enablers ABB is salient for organizational interoperability because it implements and defines the rules to manage different public administration services and matchmake the processes to provide effective responses to the public administration consumers. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/WorkflowOrchestrationInfrastructureEnablersGrouping EIF Layer: TechnicalInfrastructure Definition: Orchestration Enablers ABB is a Grouping Component that refers to the components and practices that support the development and deployment of orchestration applications. Source: ETSI Network Functions Virtualisation Standard Source reference: https://portal.etsi.org/NFV/NFV_White_Paper2.pdf Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/OrchestrationEnablersGrouping LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:OrchestrationEnablersGrouping Interoperability Saliency: The Orchestration Enablers Grouping ABB is salient for interoperability because it contains both, application services and components, that can enable the deployment and development of orchestration services. By enabling and promoting orchestration, the grouping can contribute to the creation and functioning of an interoperable ecosystem that can foster the digital public services interoperability Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/OrchestrationEnablersGrouping EIF Layer: TechnicalApplication Definition: Shared Legal Content ABB is a Grouping setting legal (re)usable resources with convergence power, to public policy goals attainment, enabling to reuse and share legislations and cross-legal jurisdiction as key enablers for the creation of interoperable digital public services. Source: EUR-LEX Source reference: (https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32021R0695&qid=1646736486403) Last modification: 2023-11-20 Identifier: http://data.europa.eu/dr8/SharedLegalContentGrouping LOST view: Legal view EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:SharedLegalContentGrouping Synonym: ABC Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): The past years have seen an extraordinary proliferation of sharing economy platforms, and the largest platforms have fast become global enterprises with market capitalisations that exceed competitors with “traditional” business concepts. These developments call into question a number of regulatory matters and pose new questions for national and European-level regulators. (https://www.intereconomics.eu/contents/year/2017/number/1/article/regulating-the-european-sharing-economy-state-of-play-and-challenges.html). Interoperability Saliency: The Shared Legal Content ABB is a key interoperability enabler (*) for governance, behavioural and structural interoperability because it supports to achieve of it with public policy goals convergence value by enabling i) sharing/provisioning/reusing/consumption of legislation on digital public services, ii) the exchange of data, information, and knowledge between digital public services, and iii) collaboration between digital public services. Additional information: The degree of achievement could range from an ideal perfect shared legal framework (i.e. no interoperability barriers from the legal perspective) to an imperfect or even null shared legal framework (i.e. some interoperability barriers from the legal perspective). The level of legal interoperability will constrain digital public services cross-legal jurisdictions. Interoperability Dimension: Structural IoP Viewpoint: Highlevel viewpoint Additional identifier: http://data.europa.eu/dr8/SharedLegalContentGrouping EIF Layer: Legal Definition: Shared Infrastructure Content ABB is a Grouping setting infrastructure (re)usable resources, with convergence power, in relation to public policy goals attainment, enabling to reuse and share IT resources to support technical aspects for the infrastructure of interoperable Digital Public Services. It provides a unified IT environment encompassing hardware, software, and processes, promoting secure and efficient resource utilization across multiple stakeholders. This shared infrastructure ensures data integrity, operational efficiency, and effective collaboration while maintaining strict data and operational separation for confidentiality and reliability. Source: Joinup Source reference: https://joinup.ec.europa.eu/collection/nifo-national-interoperability-framework-observatory/glossary/term/shared-infrastructure Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): ISO 19941 Cloud Computing Interoperability and Portability – This specification focuses on cloud computing interoperability and portability types, the relationship, and interactions between these two cross-cutting aspects of cloud computing and common terminology and concepts used to discuss interoperability and portability, particularly relating to cloud services. (https://www.iso.org/standard/66639.html) Last modification: 2024-01-08 Identifier: http://data.europa.eu/dr8/SharedInfrastructureContentGrouping LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:SharedInfrastructureContentGrouping Interoperability Saliency: Shared Infrastructure Content ABB is a key interoperability enabler (*) for structural, behavioural and governance interoperability. This ABB is salient for infrastructure interoperability with public policy goals convergence value by enabling i) determines the tools and services that can be used by stakeholders ii) determines other digital services to interconnect services and data, and iii) establish security standards compliance to deliver such public services. Interoperability Dimension: Structural IoP Viewpoint: Highlevel viewpoint Additional identifier: http://data.europa.eu/dr8/SharedInfrastructureContentGrouping EIF Layer: TechnicalInfrastructure Definition: Content Delivery Infrastructure Enablers ABB is a Grouping that refers to the set of components and services that enable the delivery of digital content such as web pages, videos, images, and audio files to end-users Source: Inspired in the definition provided by relebant cloud service organizations. Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/ContentDeliveryInfrastructureEnablersGrouping LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:ContentDeliveryInfrastructureEnablersGrouping Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): DIGIT/C Hosting Service - DIGIT/C offers a high availability and high performance hosting infrastructure that is being comprised, among other elements, of back-end web server instances and application servers for hosting and serving both static and dynamic sites. http://ec.europa.eu/ipg/build/infrastructure/index_en.htm Interoperability Saliency: Content Delivery Infrastructure Enablers ABB is salient for semantic and technical interoperability because it provides ICT systems to manipulate, reuse and share batch and streaming data related to public administration services. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/ContentDeliveryInfrastructureEnablersGrouping EIF Layer: TechnicalInfrastructure Definition: Interoperability Non-Functional Requirements Catalogue ABB is a Grouping of technical specifications and capabilities that enable different systems, applications, or devices to exchange information and work together seamlessly Source: EIRA Team Research Additional information: The Digital Solution Non-Functional Requirements Catalogue ABB includes various elements such as Extensibility, Observability, Security, Agility, Resiliency, Consistency, Scalability, Availability, Usability, and Durability. Each of these elements has a specific role and importance in the overall system design and operation. For instance, Extensibility refers to the system's ability to accommodate future changes or additions seamlessly, while Observability refers to the system's ability to monitor and analyze its behavior in real-time. Similarly, Security refers to the system's ability to protect itself against unauthorized access and data breaches, while Agility refers to the system's ability to adapt quickly to changing business needs or market conditions. The catalogue also includes various sub-elements under each main element, providing a comprehensive list of non-functional requirements for digital solutions. Example: An example of applying the Digital Solution Non-Functional Requirements Catalogue ABB could be during the design and development of a new digital banking application. The developers would need to consider various non-functional requirements such as Security (to protect users' financial information), Availability (to ensure the app is always accessible), Usability (to ensure the app is user-friendly), Scalability (to handle increasing number of users), and Extensibility (to easily add new features in the future). Additionally, they would also need to consider sub-elements such as Confidentiality and Integrity under Security, Accessibility and Learnability under Usability, and Disaster Recovery and Recoverability under Resiliency. LOST view: Digital Solution Non-Functional Requirements Catalogue view Identifier: http://data.europa.eu/dr8/egovera/DigitalSolutionNon-FunctionalRequirementsCatalogueGrouping ABB name: egovera:DigitalSolutionNon-FunctionalRequirementsCatalogueGrouping EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-08-17 dct:identifier: http://data.europa.eu/dr8/egovera/DigitalSolutionNon-FunctionalRequirementsCatalogueGrouping dct:title: Digital Solution Non-Functional Requirements Catalogue Catalogue Definition: Extensibility Requirements Catalogue ABB is a grouping that covers a set of non-functional requirements that pertain to the adaptability and scalability of a software system. It includes elements such as modularity and reusability, and pluggability, which are crucial for creating flexible, efficient, and effective software systems that can be easily maintained, updated, and integrated with other systems or components. Source: EIRA Team Research Additional information: The Extensibility Requirements Catalogue ABB is a comprehensive collection of non-functional requirements that are essential for the development of scalable and adaptable software systems. The catalogue includes 'Modularity and reusability', which refers to the ability of a software system to be broken down into smaller, independent components that can be reused in other parts of the system or in other systems. This requirement is crucial for reducing development time and effort, and for creating more efficient systems. The catalogue also includes 'Pluggability', which refers to the ability of a system to easily integrate with other systems or components without requiring significant code modifications. This requirement is vital for systems that need to be scalable and adaptable to changing business requirements. Example: An example of the application of the Extensibility Requirements Catalogue ABB could be in the development of a large-scale enterprise software system. The system could be designed with modularity and reusability in mind, allowing for the easy reuse of components across different parts of the system. Additionally, the system could be designed to be pluggable, enabling easy integration with third-party tools and technologies, and allowing for easy customization and extension of the system's functionality as business requirements change over time. LOST view: Digital Solution Non-Functional Requirements Catalogue view Identifier: http://data.europa.eu/dr8/egovera/ExtensibilityRequirementsCatalogueGrouping ABB name: egovera:ExtensibilityRequirementsCatalogueGrouping EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-08-17 dct:identifier: http://data.europa.eu/dr8/egovera/ExtensibilityRequirementsCatalogueGrouping dct:title: Extensibility Requirements Catalogue Catalogue Definition: Digital Solution Maintainability & Quality Architecture Decision Catalogue ABB is a grouping that covers the technical architectural decisions related to the maintainability and quality of digital solutions. It includes decisions about version control, coding standards, and documentation, which are crucial for the development, maintenance, and quality assurance of software systems. Source: EIRA Team Research Additional information: The Digital Solution Maintainability & Quality Architecture Decision Catalogue ABB is a collection of architectural decision records (ADRs) that document the decisions made regarding the technical aspects of a software system's architecture. These decisions typically involve choosing specific technologies, frameworks, protocols, or design patterns. The catalogue includes decisions about version control, which is crucial for tracking changes in the software and facilitating collaboration among developers; coding standards, which ensure consistency and readability in the code; and documentation, which provides necessary information about the software to developers, users, and other stakeholders. Example: [object Object] [object Object] [object Object] LOST view: Digital Solution Architecture Decisions Catalogue view Identifier: http://data.europa.eu/dr8/egovera/DigitalSolutionMaintenabilityQualityArchitectureDecisionCatalogueGrouping ABB name: egovera:DigitalSolutionMaintenabilityQualityArchitectureDecisionCatalogueGrouping EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-08-18 dct:identifier: http://data.europa.eu/dr8/egovera/DigitalSolutionMaintenabilityQualityArchitectureDecisionCatalogueGrouping dct:title: Digital Solution Maintenability & Quality Architecture Decision Catalogue Catalogue Definition: Database Infrastructure Enablers ABB is a Groping that enables the tools and technology services for efficient management and operation of data under a storage system. Source: Inspired in Gartner Source reference: https://www.gartner.com/en/information-technology/glossary/dbms-database-management-system Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/DatabaseInfrastructureEnablersGrouping LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:DatabaseInfrastructureEnablersGrouping Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): MySQL manager, an SQL for MySQL. https://www.sqlmanager.net/products/mysql/manager Interoperability Saliency: Database Infrastructure Enablers ABB is salient for semantic and organization interoperability because it set up (i) tools to manage and manipulate data considering different types of data stores, (ii) establishes a data exchange mechanism to facilitate data understanding, (iii) manage data provenance through the public services interaction with the heterogeneous datastores. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/DatabaseInfrastructureEnablersGrouping EIF Layer: TechnicalInfrastructure Analysis of a target digital public solution is the process of evaluating a proposed or existing digital public solution to determine its suitability, feasibility, and effectiveness in meeting the needs of its intended users and stakeholders. It is a critical step in the development and implementation of digital public solutions, as it helps to ensure that the solutions are well-designed, user-friendly, and sustainable. The analysis of a target digital public solution should consider the following factors: Target audience: Who are the intended users of the solution? What are their needs, expectations, and capabilities? Functional requirements: What are the specific functions and features that the solution must provide? Non-functional requirements: What are the non-functional requirements, such as performance, security, and accessibility? Cost-benefit analysis: What are the costs and benefits of the solution? Is it a cost-effective solution? Interoperability: How will the solution interoperate with other systems and services? Is it compliant with the European Interoperability Reference Architecture (EIRA)? The analysis of a target digital public solution can be conducted using a variety of methods: User research: This involves gathering data about the needs, expectations, and capabilities of the target audience. Technical assessment: This involves evaluating the technical feasibility of the solution, including its performance, security, and accessibility. Cost-benefit analysis: This involves estimating the costs and benefits of the solution. Interoperability testing: This involves testing the solution to ensure that it is compliant with the EIRA. The results of the analysis of a target digital public solution should be documented and used to inform the development and implementation of the solution. The analysis should also be reviewed and updated as the solution evolves and new requirements emerge. Definition: Application Presentation Enablers ABB is a Grouping that enables the implementation of visually appealing and interactive user interfaces for software applications Source: Inspired in Redhat Source reference: https://www.redhat.com/architect/5-essential-patterns-software-architecture Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/ApplicationPresentationEnablersGrouping LOST view: Technical view - application EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:ApplicationPresentationEnablersGrouping Interoperability Saliency: The Application Presentation Enablers Grouping ABB is salient for interoperability because is composed of the Human Interface Application Interface which is a key interoperability enabler that facilitates the data exchange between parties using the digital public service. In addition, this is relevant for interoperability because the ABBs included can work as a tool through which to assess compatible interfaces. Interoperability Dimension: Behavioral IoP Viewpoint: Highlevel viewpoint Additional identifier: http://data.europa.eu/dr8/ApplicationPresentationEnablersGrouping EIF Layer: TechnicalApplication Definition: Digital Solution Architecture Decision Catalogue ABB is a Grouping that covers a comprehensive collection of architecture decisions related to digital solutions. It includes decisions about technical architecture, business architecture, security, privacy and compliance, high availability and resilience, scalability, portability, maintainability, quality, and usability. Each decision is documented in an Architecture Decision Record (ADR) that describes the context, decision, and consequences. Source: EIRA Team Research Additional information: The catalogue is divided into several categories, each focusing on a specific aspect of digital solution architecture. For example, the 'Digital Solution Technical Architecture Decision Catalogue' includes decisions about technology stack selection, API design, event-driven architecture, database schema design, and more. Similarly, the 'Digital Solution Business Architecture Decision Catalogue' includes decisions about cross-border identification business, dynamic location of data provider, data notification deployment, and others. Each decision is documented in an ADR, providing a record of why and how decisions were made, aiding in future understanding and decision-making. Example: An example of an element in the catalogue is 'Technology Stack Selection'. This is an ADR that documents the decision-making process for selecting the technology stack for a digital solution. It would include the context (why the decision was needed), the decision (what was decided), and the consequences (the impact of the decision). LOST view: Digital Solution Architecture Decisions Catalogue view Identifier: http://data.europa.eu/dr8/egovera/DigitalSolutionArchitectureDecisionCatalogueGrouping ABB name: egovera:DigitalSolutionArchitectureDecisionCatalogueGrouping EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-08-18 dct:identifier: http://data.europa.eu/dr8/egovera/DigitalSolutionArchitectureDecisionCatalogueGrouping dct:title: Digital Solution Architecture Decision Catalogue Catalogue Definition: Usability Requirements Catalogue ABB is a grouping that covers a range of non-functional IT requirements that are crucial for ensuring the usability and accessibility of a system or application. This includes requirements related to accessibility, learnability, and API contracts. Each of these elements plays a key role in ensuring that the system or application is user-friendly, inclusive, and efficient, and that it complies with relevant laws and regulations. Source: EIRA Team Research Additional information: The Usability Requirements Catalogue ABB is a comprehensive collection of non-functional requirements that are essential for the development of user-friendly and accessible IT systems and applications. The catalogue includes 'Accessibility', which ensures that the system can be used by people with disabilities or impairments; 'Learnability', which measures how quickly and efficiently users can learn to use the system; and 'API contract', which specifies the rules and guidelines for how an API should behave. By adhering to these requirements, developers can create systems and applications that are inclusive, efficient, and compliant with relevant laws and regulations. Example: For instance, when developing a new web application, a developer might refer to the Usability Requirements Catalogue ABB to ensure that the application is accessible to users with disabilities. This could involve implementing features such as screen readers, keyboard navigation, and alternative text for images. The developer might also use the catalogue to ensure that the application is easy to learn and use, by creating clear and intuitive interfaces and providing well-organized documentation and help resources. Finally, the developer might refer to the 'API contract' requirement to ensure that the application's API is consistent, predictable, and easy to integrate with other systems. LOST view: Digital Solution Non-Functional Requirements Catalogue view Identifier: http://data.europa.eu/dr8/egovera/UsabilityRequirementsCatalogueGrouping ABB name: egovera:UsabilityRequirementsCatalogueGrouping EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-08-17 dct:identifier: http://data.europa.eu/dr8/egovera/UsabilityRequirementsCatalogueGrouping dct:title: Usability Requirements Catalogue Catalogue Definition: Security Requirements Catalogue ABB is a grouping that covers a range of non-functional IT requirements that are critical for ensuring the security, integrity, and reliability of a system or application. These requirements include confidentiality, integrity, nonrepudiation, accountability, authenticity, auditability, authentication, authorization, legality, compliance, and privacy. Each of these elements plays a crucial role in protecting sensitive information, preventing unauthorized access or modification, ensuring compliance with laws and regulations, and maintaining the trustworthiness and credibility of the system. Source: EIRA Team Research Additional information: The Security Requirements Catalogue ABB is a comprehensive collection of IT security requirements that are essential for any system or application that handles sensitive data. These requirements are designed to protect the data from unauthorized access, ensure its accuracy and consistency, provide proof of transactions, track user activities, verify user identities, grant appropriate access levels, comply with legal and regulatory standards, and safeguard privacy. Failure to meet these requirements can result in security breaches, loss of data integrity, legal penalties, and loss of trust among users and stakeholders. Example: For example, a healthcare application would need to meet the requirements of confidentiality to protect patient data, integrity to ensure the accuracy of medical records, nonrepudiation to provide proof of medical orders, accountability to track user activities, authenticity to verify the genuineness of data, auditability to provide a record of transactions, authentication to verify user identities, authorization to grant appropriate access levels, legality to comply with healthcare regulations, compliance to adhere to data protection standards, and privacy to safeguard patient privacy. LOST view: Digital Solution Non-Functional Requirements Catalogue view Identifier: http://data.europa.eu/dr8/egovera/SecurityRequirementsCatalogueGrouping ABB name: egovera:SecurityRequirementsCatalogueGrouping EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-08-17 dct:identifier: http://data.europa.eu/dr8/egovera/SecurityRequirementsCatalogueGrouping dct:title: Security Requirements Catalogue Catalogue Definition: Resiliency Requirements Catalogue ABB is a grouping that covers a set of non-functional IT requirements that are designed to ensure that a system can withstand and recover from various types of disruptions, including catastrophic events, system failures, and errors. The catalogue includes elements such as 'Disaster Recovery' and 'Recoverability', which outline the strategies and mechanisms needed to minimize the impact of such events on system functionality and data, and to ensure system availability and business continuity. Source: EIRA Team Research Additional information: The Resiliency Requirements Catalogue ABB is a comprehensive collection of non-functional IT requirements that focus on the system's ability to bounce back from disruptions. The 'Disaster Recovery' element refers to the strategies and procedures that need to be in place to recover from catastrophic events, such as natural disasters, power outages, or cyber-attacks. This includes backup and recovery procedures, redundant systems, and failover mechanisms. The 'Recoverability' element, on the other hand, refers to the system's ability to recover from failures or errors and return to its normal functioning. This involves implementing backup and recovery mechanisms, such as data replication, redundancy, and failover. Example: An example of the application of the Resiliency Requirements Catalogue ABB could be in the development of a cloud-based data storage system. The 'Disaster Recovery' element would involve creating a detailed plan for how the system would recover from a catastrophic event, such as a major power outage or a cyber-attack. This could include strategies such as regular data backups, the use of redundant systems, and the implementation of failover mechanisms. The 'Recoverability' element would involve ensuring that the system has the ability to recover data, configurations, and settings after a system crash or other disruptions. This could involve the use of data replication, redundancy, and failover mechanisms. LOST view: Digital Solution Non-Functional Requirements Catalogue view Identifier: http://data.europa.eu/dr8/egovera/ResiliencyRequirementsCatalogueGrouping ABB name: egovera:ResiliencyRequirementsCatalogueGrouping EIRA concept: eira:ArchitectureBuildingBlock Last modification: 2023-08-17 dct:identifier: http://data.europa.eu/dr8/egovera/ResiliencyRequirementsCatalogueGrouping dct:title: Resiliency Requirements Catalogue Catalogue Definition: Digital Workplace Infrastructure Enablers ABB is a Grouping that enables the set of components and services that enable organizations to create and manage virtual workplaces environments and facilitate their access remotely. Source: Inspired in Gartner Source reference: https://www.gartner.com/en/information-technology/glossary/remote-access Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/DigitalWorkplaceInfrastructureEnablersGrouping LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:DigitalWorkplaceInfrastructureEnablersGrouping Example: The following implementation is an example on how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): PSI Remote Desktop Service from the European Open Science Cloud https://marketplace.eosc-portal.eu/services/remote-desktop-service?from_recommendation_panel=true&fromc=access-physical-einfrastructures Interoperability Saliency: Digital Workplace Infrastructure Enablers ABB is salient for technical interoperability due to it refers to setting up the workplace ecosystem to establish access to European public services remotely to access applications using open specifications and interfaces. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/DigitalWorkplaceInfrastructureEnablersGrouping EIF Layer: TechnicalInfrastructure Definition: Storage Infrastructure Enablers ABB is a Grouping of a set of tools and digital services that facilitate the efficient and effective storage of data Source: TECHNOPEDIA Source reference: https://www.techopedia.com/definition/30476/storage-infrastructure Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/StorageInfrastructureEnablersGrouping LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:StorageInfrastructureEnablersGrouping Example: The following implementation is an example of how this specific Architecture Building Block (ABB) can be instantiated as a Solution Building Block (SBB): GARTNER- Distributed File Systems and Objects Storage Reviews and Ratings. https://www.gartner.com/reviews/market/distributed-file-systems-and-object-storage Interoperability Saliency: Storage Infrastructure Enablers ABB is salient for technical interoperability because it establishes the mechanism to (i) ensure the correct management of the information across single or multiple infrastructures, and (ii) minimize the effects of data loss in case of unexpected behaviour of public services through data recovery strategies. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/StorageInfrastructureEnablersGrouping EIF Layer: TechnicalInfrastructure Definition: Facility Location ABB is a Location conceptual or physical place or position where a bussiness organization is placed. Source: Inspired in Archimate Source reference: https://pubs.opengroup.org/architecture/archimate3-doc/chap04.html Last modification: 2024-01-28 Identifier: http://data.europa.eu/dr8/FacilityLocationLocation LOST view: Technical view - infrastructure EIRA concept: eira:ArchitectureBuildingBlock ABB name: eira:FacilityLocationLocation Interoperability Saliency: Facility Location ABB is salient for the organizational and technical interoperability because of (i) it determines the interlink between public administration business process removing existing barriers; (ii) set up needed mechanism between IT systems to remove fragmentation in service delivery. Interoperability Dimension: Structural IoP Additional identifier: http://data.europa.eu/dr8/FacilityLocationLocation EIF Layer: TechnicalInfrastructure This relationship has been converted from "aggregation" to "association" A [Public Service Catalogue] documents a [Public Service] This relationship has been converted from "aggregation" to "association" a [Data Policy] influences [Data] A [Representation] represents [Data] This relationship has been converted from "composition" to "association" This relationship has been converted from "specialization" to "association" This relationship has been converted from "realization" to "association" A [Public Service] implements a [Public Policy] The EIRA© API viewpoint models an introductory overview of the focal Architecture Building Blocks required when modelling an API Interface. The ABBs included in the API viewpoint represent all the required Building Block necessary to design an API Interface accessible thoruh a web interface. Narrative: A [Client request for service] is made trough [Internet] and it triggers the [Authentication Service] which serves the [Request Validation Service]that triggers the [HTTP(s) Load Balancer] whichin turn triggers all the [Endpoints] related. Each [Endpoint] serves the [Application Service] which triggers the [App Component] that, in turn, triggers the [Data Access Service]. The [Data Access Service] provides access to the [Data Space] which is composed by the [SQL Data Space], [Read - Replica], [NoSQL Data Space] and [Virtual Data Space]. In the moment in which the [Endpoint] is triggered data flows to the [API Response] which is composed by [Data] and [Represenation] accessed by a [Request Validation Service]. The [API Response] triggers the response that is provided to the user who requetd the data in the first instance. The European Interoperability Framework underlying principles view models the motivation of the EIRA© in terms of goals to be achieved and the principles to be followed in order to achieve interoperability in public services. The interoperability principles are fundamental behavioural aspects to drive interoperable public services. They describe the context in which European public services are designed and implemented. The twelve underlying principles of the EIF are grouped into four categories: 1. Principle setting the context for EU actions on interoperability (Subsidiarity and proportionality); 2. Core interoperability principles (Openness, Transparency, Reusability, Technological neutrality and data portability); 3. Principles related to generic user needs and expectations (User-centricity, Inclusion and accessibility, Security and privacy, Multilingualism); 4. Foundation principles for cooperation among public administrations (Administrative simplification, Preservation of information, Assessment of Effectiveness and Efficiency). The "Not Implemented Architecture Principles Catalogue": Despite the vital role architecture principles play, there are situations where certain principles may not be employed within a specific solution architecture. It is important to maintain transparency and ensure that these omissions are duly noted and communicated. The "Not Implemented Architecture Principles Catalogue" serves as a repository for documenting such cases. Including explanatory notes alongside each omitted principle is crucial. These notes should provide a clear rationale for the exclusion, explaining the context, constraints, or trade-offs that led to the decision. By doing so, the documentation acts as a reference for future architects, fostering a deeper understanding of the architectural choices made and promoting informed decision-making. Benefits of Documenting Omitted Principles: Knowledge Sharing: The catalogue facilitates knowledge sharing among architects by capturing the context and rationale behind each omitted principle. This ensures that valuable insights are not lost, enabling future architects to make informed decisions based on prior experiences. Governance and Compliance: The documentation of omitted principles helps ensure that architectural decisions align with organizational governance frameworks and compliance requirements. It provides visibility into the reasons behind deviations from standard architectural practices, allowing stakeholders to assess risks and make informed judgments. Risk Management: Identifying and acknowledging the absence of certain architecture principles helps uncover potential risks and trade-offs associated with the solution architecture. It enables architects to proactively address these risks and develop mitigation strategies. Continuous Improvement: The documentation of omitted principles promotes a culture of continuous improvement. It encourages architects to revisit decisions, reassess trade-offs, and learn from past experiences, ultimately refining their approach to solution architecture. The European Interoperability Framework underlying principles view models the motivation of the EIRA© in terms of goals to be achieved and the principles to be followed in order to achieve interoperability in public services. The interoperability principles are fundamental behavioural aspects to drive interoperable public services. They describe the context in which European public services are designed and implemented. The twelve underlying principles of the EIF are grouped into four categories: 1. Principle setting the context for EU actions on interoperability (Subsidiarity and proportionality); 2. Core interoperability principles (Openness, Transparency, Reusability, Technological neutrality and data portability); 3. Principles related to generic user needs and expectations (User-centricity, Inclusion and accessibility, Security and privacy, Multilingualism); 4. Foundation principles for cooperation among public administrations (Administrative simplification, Preservation of information, Assessment of Effectiveness and Efficiency). Narrative: The twelve interoperability principles of the New EIF ([Subsidiarity and proportionality], [Openness], [Transparency], [Transparency], [Technological neutrality and data portability], [User-centricity], [Inclusion and accessibility], [Security and privacy], [Multilingualism], [Administrative simplification], [Preservation of information] and [Assessment of Effectiveness and Efficiency]) together fulfil the goals of achieving interoperability: [Achieve Legal Interoperability], [Achieve Organisational Interoperability], [Achieve Semantic Interoperability] and [Achieve Technical Interoperability]. Source: The New EIF. https://ec.europa.eu/isa2/eif_en The new European Interoperability Framework (EIF) is part of the Communication (COM(2017)134) from the European Commission adopted on 23 March 2017. The framework gives specific guidance on how to set up interoperable digital public services. Authorization is not mentioned Certificaciones (PKI) Certification of participants Actualizar The Interoperability Security and Privacy viewpoint models the most salient Architecture Building Blocks related to both security and privacy in the domain of interoperability. Citizens and businesses must be confident that when they interact with public authorities they are doing so in a secure and trustworthy environment and in full compliance with relevant regulations, e.g. the Regulation and Directive on data protection, and the Regulation on electronic identification and trust services. Public administrations must guarantee the citizens’ privacy, and the confidentiality, authenticity, integrity and non-repudiation of information provided by citizens and businesses. Security and privacy are primary concerns in the provision of public services. When public administrations and other entities exchange official information, the information should be transferred, depending on security requirements, via a secure, harmonised, managed and controlled network. Transfer mechanisms should facilitate information exchanges between administrations, businesses and citizens. Appropriate mechanisms should allow secure exchange of electronically verified messages, records, forms and other kinds of information between the different systems; should handle specific security requirements and electronic identification and trust services such as electronic signatures/seals creation and verification; and should monitor traffic to detect intrusions, changes of data and other type of attacks. Source: The New EIF https://ec.europa.eu/isa2/sites/isa/files/eif_brochure_final.pdf Narrative: This viewpoint selects Architecture Building Blocks from the five different view highlighting the Security and Privacy aspects of the EIRA©: 1. The selected Architecture Building Block of the legal view shows the [Public Policy], which is that mainspring of the solution 2. The selected Architecture Building Block of the organisational view shows the [Security Framework], associated with the [Security Governance] which is that mainspring of the solution. 3. The selected Architecture Building Block of the semantic view shows the [Security Policy], which is that mainspring of the solution. 4. The selected Architecture Building Blocks of the technical view Application shows that a [Interoperable Digital Solution], which considers [Human Interface] and [Machine to Machine Interface] is supported by a [Shared platform] which uses [Trust Enablers], [Application Security Enablers], [Identification and Access Enablers] and [Data Exchange Enablers]. [Trust Enablers] such as [Integrity Verification Service], [e-Signature Creation Service], [e-Seal Creation Service], [e-Timestamp Creation Service], [e-Signature Verification and Validation Service], [e-Seal Verification and Validation Service], [e-Timestamp Verification and Validation Service], [e-Signature Preservation Service], [e-Seal Preservation Service] and [Registered Electronic Delivery Service], are all realised by a [Trust Service Provisioning Component]. [Identification and Access Enablers] is composed of [Authentication Service], [Request Validation Service] and [Registration Service] which are realised by [Identification Component] and that provides access to the [Directory], accessed also by the [Access Management Service], realised by the [Access Management Component]. [Application Security Enablers] is realised of [Firewall Service], composed of [Firewall Component] and [Audit Service], which is realised by an [Audit Component]. [Data Exchange Enablers] composed of Data Exchange Service] realised by the [Data Exchange Component]. 5. The selected Architecture Building Blocks of the technical view Infrastructure shows an [Outsourcing Facility] and [On - Premise Facility] composed of [Back End Firewall] and [Extranet Firewall]. 5. The selected Architecture Building Blocks of the EIF Underlying Principles view show that [Interoperability Specifications] realises [EIF Principles], the general intended properties used to achieve interoperability, of which the [Security and Privacy] is a specialisation. The interoperability Specifications can be used to define the interoperability aspects for any of the Architecture Building Blocks . An Application Processing Enabler is the collection of mediation enablers and decision support enablers. A Mediation Enabler is a service or component for the routing, transformation, validation and exchange of data. The Interoperability Privacy viewpoint highlights the EIRA building blocks that are relevant when implementing the EU General Data Protection Regulation (GDPR) or assessing an existing architecture against the GDPR principles. Public administrations must indeed guarantee the citizens’ privacy, and the confidentiality, authenticity, integrity and non-repudiation of information provided by citizens and businesses. Narrative: The selected Architecture Building Blocks from the five different views highlight the Architecture Building Blocks of the EIRA that are that are relevant with respect to GDPR: 1. The selected Architecture Building Blocks of the legal view show that privacy requirements are coming from a [Public Policy] realised by a [Binding instrument]. 2. The selected Architecture Building Blocks of the organisational view show that the [Privacy Framework] applies to the [Digital Public Service] which is assigned by the [Data Owner] and provided by the [Digital Public Service Provider]. The [Digital Public Service] serves the [Digital Public Service Delivery Consumer], assigned to an [Individual] that is associated to the [Information] accessible though the [Organisation] which is a specialissed by [Public Administration] and [Business]. 3. The selected Architecture Building Blocks of the semantic view show that [Data] aggregates [Data Set], [Ontology] and [Data Mapping] and that it is subject to the [Data Policy]. 4. The selected Architecture Building Blocks of the Technical View shows many service involving data impacted by the privacy regulation, such as [Data Extraction,Transformation and Loading Service], [Data Quality Service], [e-Archiving Service], [Data Publication Service], [Data Exchange Service] and [Data Management Service]; all the services reported are realised by their specific Application Component. Additionally, a [Privacy Service], realised by a [Privacy Component] implementing GDPR principle can be used to ensure compliance. 5. The selected Architecture Building Block of the EIF Underlying Principles view show the [EIF Principle], the general intended properties used to achieve interoperability, of which the [Security and Privacy] is a specialisation. The interoperability Specifications can be used to define the interoperability aspects for any of the Architecture Building Blocks. The EIRA© Highlevel viewpoint models an introductory overview of the focal Architecture Building Blocks of each view. The ABBs included in the high-level viewpoint represent the points that link the EIRA©’s views enabling traceability between their different Architecture Building Blocks. They are not necessarily mandatory but should always be considered by a user of the EIRA© when executing one of its use cases. The EIRA© with its views provides a set of Architecture Building Blocks, important to facilitate interoperability. Each view, one for each interoperability level, is represented with the Focal Architecture Building Blocks needed to deliver an interoperable solution. These focal Architecture Building Blocks are indicated with an accented colour. In the high-level are represented the ABBs that link the EIRA©’s views enabling navigation between the different views. As such they should be considered as critical components of any interoperable public service. They are not necessarily mandatory but should always be considered by a user of the EIRA© when executing one of its use cases. Narrative: This viewpoint selects Architecture Building Blocks from the five different views highlighting the focal building blocks of the EIRA©: 1. The selected Architecture Building Block of the legal view shows the [Public Policy] is realised by [Legal Act] and [Digital Public Service]; these two ABB, referred to the legal view, are aggregated within the [Shared Legal framework]. [Shared legal Framework] influences [Organisational Functional Content], [Semantic Functional Content], [Technical Application Functional Content]. 2. The selected Architecture Building Blocks of the organizational view show a [Shared Governance Framework] that aggregates the [Organizational Functional Content] which considers a [Digital Public Service] which can be an aggregation of other [Digital Public Service]. The [Digital Public Service] realises a [Digital Business Capability]. A [Digital Business Capability] describes key functions supporting the [Digital Public Service]. A [Digital Public Service] accesses [Information], which can be an aggregation of other [Information]. At the same time a [Digital Public Service] is assigned by a [Digital Public Service Delivery] which is connected through a serving relation with the [Digital Public Service Delivery Model]. 3. The selected Architecture Building Blocks of the semantic view shows the [Shared Knowledge Base] and that the [Semantic Functional Content] is composed of a [Representation], stored as [Data] and the [Ontology]. 4. The selected Architecture Building Blocks of the technical views - application shows that a [Interoperable Digital Solution Service] is composed of a [Digital Solution Service] realized by a [Digital Solution Component] and lets consumers access it via [Machine to Machine Interface] and/or [Human Interface], which are part of a [Application Presentation and Access Enablers]. A [Digital Solution] exposes one or more [Digital Solution Service] via its [Machine to Machine Interface] and/or [Human Interface]. The [Digital Solution] uses [Digital Service Infrastructure] which uses a [Computing Hosting, Networking, and Data Hosting Infrastructure]. 5. The selected Architecture Building Blocks of the technical views - infrastructure considers the [Computing Hosting, Networking and Data Hosting Infrastructure]. The IT Architecture Decision Records (ADRs) catalogue of a digital solution refers to a collection of documents that capture and document important architectural decisions made during the development and evolution of the solution. These records serve as a valuable reference for the project team, stakeholders, and future developers, providing insights into the rationale behind key design choices and the impact of those decisions. The ADR catalogue typically includes the following elements: + Title/Identifier: Each ADR is assigned a unique title or identifier to enable easy identification and retrieval. + Context: This section provides a brief overview of the background and context that led to the architectural decision. It may include factors such as business requirements, technical constraints, or market considerations. + Decision: This section outlines the specific decision made, describing the chosen solution or approach in detail. It should clearly articulate the problem being addressed and the solution chosen. + Alternatives Considered: It is essential to document alternative solutions or approaches that were evaluated before settling on the chosen decision. This helps to understand the reasoning behind the selected option. + Rationale: The rationale section explains the reasoning behind the decision. It may include factors such as performance, scalability, security, cost, maintainability, compatibility, or other relevant considerations. + Implications: This section discusses the potential impact of the decision on the system, including any anticipated benefits, drawbacks, risks, or dependencies introduced by the chosen approach. + Related ADRs: If the decision has dependencies or relationships with other ADRs, those connections should be documented in this section. It helps in establishing the traceability and understanding the interconnectedness of decisions. + Status and Date: Each ADR should include the current status (e.g., proposed, accepted, rejected, superseded) and the date when the decision was made or recorded. By maintaining a comprehensive ADR catalogue, organizations can foster transparency, facilitate collaboration, and ensure consistency in architectural decision-making across teams and projects. It serves as a knowledge repository and assists in understanding the evolution and reasoning behind the architecture of a digital solution. A non-functional requirements catalog for a digital solution includes a set of criteria and characteristics that describe how the solution should perform, rather than what it should do. These requirements focus on aspects such as performance, security, usability, reliability, and other quality attributes that determine the overall effectiveness and user experience of the solution. Here are some common categories of non-functional requirements that are often included in such a catalog: + Performance: Defines the speed, responsiveness, scalability, and efficiency of the solution under varying conditions, such as user load, data volume, or network latency. + Usability: Specifies the ease of use, intuitiveness, and accessibility of the solution, ensuring that it meets the needs and expectations of its intended users. + Reliability: Addresses the solution's ability to consistently perform its functions accurately and reliably over time, minimizing downtime and data loss. + Security: Covers the protection of data, information, and system resources against unauthorized access, tampering, or breaches. It may include aspects such as authentication, encryption, and compliance with relevant security standards. + Availability: Describes the solution's uptime requirements, including its ability to remain accessible and operational during scheduled maintenance or unexpected outages. + Scalability: Defines the solution's ability to handle increasing workload or user demand by efficiently utilizing resources and adapting to changing circumstances. + Maintainability: Refers to the ease of maintaining and modifying the solution, including aspects such as code maintainability, documentation, and the availability of development and debugging tools. + Interoperability: Specifies the solution's ability to integrate and communicate with other systems or components, often through the use of standardized protocols or interfaces. + Compliance: Ensures that the solution adheres to relevant laws, regulations, and industry standards, such as data protection regulations or accessibility guidelines. + Performance Efficiency: Focuses on optimizing resource usage, minimizing energy consumption, and maximizing the efficiency of the solution's operations. + Testability: Defines the ease with which the solution can be tested to ensure that it meets its functional and non-functional requirements, often through the use of automated testing tools and techniques. + Internationalization and Localization: Addresses the solution's ability to support multiple languages, regions, and cultural conventions to cater to a global user base. These are just some examples of non-functional requirements that may be included in a catalog for a digital solution. The specific requirements will depend on the nature of the solution, its intended use, and the stakeholders' needs. The Enterprise Architecture Framework (EAF) alignment guidelines viewpoint serves as an integral part of the process, aiming to establish a harmonious relationship between the European Interoperability Reference Architecture (EIRA) model and any given Enterprise Architecture Framework (EAF). The ultimate goal is to make the EIRA model fully compliant with the chosen EAF, promoting uniformity across the architectural ecosystem. In this alignment diagram, each Architectural Building Block (ABB) carries a specific connection to the EIRA's Legal, Organisational, Semantic, and Technical (LOST) views that it belongs to. Each ABB forms a critical component of the architecture, representing distinct facets of the EIRA in the broader context of the selected EAF. This viewpoint connects different layers of the enterprise architecture, creating a comprehensive picture of the interoperability landscape. The intricate ties between each ABB and their corresponding LOST views can be thoroughly explored on the [Properties] sheet under the [Analysis] tab of Archi, a visual modelling and management tool for enterprise architecture. Here, users can investigate each ABB, understanding its role, its relationship with the LOST views, and its part in securing compliance with the EAF. The EAF alignment guidelines viewpoint allows organizations to align with industry standards, facilitates interoperability, and bridges the EIRA model with the selected EAF. It assists an organization in effectively detailing their enterprise architecture in line with their specific needs while maintaining alignment with larger industry frameworks. The viewpoint provides a structured layout, enhancing strategic decision-making, facilitating effective communication, and aiding the integration of different architectural elements. This organized alignment fortifies the architecture's robustness and provides a pathway for strategic expansion and evolution. The Key Interoperability Enablers viewpoint models the most salient key interoperability enablers(*). The viewpoint uses the ArchiMate© motivation extension to assess the structural interoperability readiness, the behavioral interoperability readiness and the governance interoperability readiness of solutions that are necessary to enable the efficient and effective delivery of public services across administrations. European public service provision often requires different public administrations to work together to meet end users’ needs and provide public services in an integrated way. When multiple organizations are involved there is a need for coordination and governance by the authorities with a mandate for planning, implementing and operating European public services. Services should be governed to ensure: collaboration, seamless execution, reuse of services and data, and development of new services and ‘building blocks'. (*)DECISION (EU) 2015/2240 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 25 November 2015 establishing a programme on interoperability solutions and common frameworks for European public administrations, businesses and citizens (ISA2 programme) as a means for modernising the public sector. The Key Interoperability Enablers viewpoint covers all EIF interoperability aspects: legal, organisational, semantic and technical. Ensuring interoperability when preparing legal instruments, organisation business processes, data/information/knowledge exchange, services and components that support European interoperable digital public services is a continuous task, as interoperability is regularly disrupted by changes to the environment, i.e. in legislation, the needs of businesses or citizens, the organisational structure of public administrations, the business processes, and by the emergence of new technologies. Source: The New EIF https://ec.europa.eu/isa2/sites/isa/files/eif_brochure_final.pdf Narrative: This viewpoint selects Architecture Building Blocks of the EIRA© that are key enablers for the interoperability of public services: 1. EIF [Interoperability Principles] are used to realise the overall goal of achieving interoperability. 2. Particularly, the goal of [Achieve Legal Interoperability] is realised by a [Shared Legal Framework] of [re]usable legal resources that enables: structural interoperability by legal resources supporting reusing and/or sharing legislation (i.e. [Legislation Catalogue] enabling provisioning/consuming legal texts cross public administrations and cross borders); behavioral interoperability by legal resources supporting exchanging capabilities of data, information or knowledge with internal/external peers (i.e. [Legislation on Data Information and Knowledge Exchange] enabling data/information/knowledge to be provisioned/consumed cross public administrations and cross borders); and governance interoperability by legislation supporting the collaboration with internal/external peers exchanging data, information or knowledge (i.e. [Legal Interoperability Agreement] on legal terms assuring juridical certainty enabling agreed legal terms/conditions for sharing, reuse and exchange of data/information/knowledge cross public administrations and cross borders). 3. Particularly, the goal of [Achieving Organisational Interoperability] is realised by a [Shared Governance Framework] of [re]usable organisational resources that enables: structural interoperability by organisational resources supporting reusing and/or sharing of digital public services (i.e. [Digital Public Service Catalogue] enabling provisioning/consuming public services cross public administrations and cross borders); behavioural interoperability by organisational resources supporting exchanging capabilities of data, information or knowledge with internal/external peers (i.e. [Digital Public Service Delivery Model], served by [Digital Public Service Delivery] enabling data/information/knowledge to be provisioned/consumed cross public administrations and cross borders); and governance interoperability by governance resources supporting the collaboration with internal/external peers exchanging data, information or knowledge (i.e. [Organisational Interoperability Agreement] on organisational terms/conditions enabling sharing, reuse and exchange of data/information/knowledge cross public administrations and cross borders). 4. Particularly, the goal of [Achieving Semantic Interoperability] is realized by a [Shared Knowledge Base] of usable data, information and knowledge resources that enables: structural interoperability by semantic resources supporting reusing and/or sharing of data, information and knowledge (i.e. [Data Set Catalogue], [Ontologies Catalogue] and [Data Mapping Catalogue] enabling provisioning/consuming data, information and knowledge cross public administrations and cross borders); behavioral interoperability by semantic resources supporting exchanging capabilities of data, information or knowledge with internal/external peers (i.e. [Open Data], [Distributed Ledger] and [Virtual Data Set]; and governance interoperability by semantic resources supporting the collaboration with internal/external peers exchanging data, information or knowledge (i.e. [Semantic Interoperability Agreement] on interpretations enabling sharing, reuse and exchange of data/information/knowledge cross public administrations and cross borders). 5. Particularly, the goal of [Achieving Technical Interoperability] is realised by a [Shared Application Content] and [Shared Infrastructure Content]. The [Shared Application Content] is a Grouping of ICT Resources components that enables structural interoperability by ICT resources supporting the reusing and sharing of data via [Software component Discovery and catalogue Service], [API Discovery and Catalogue Service] and [Service Discovery and Registry Service]; behavioural interoperability by ICT resources supporting communication via [Machine to Machine], [Human Interface], [Data Exchange Service], [UX Management Service] and [Digital Workplace Service], and governance interoperability by ICT resources supporting collaboration via [Technical Interoperability Agreements]. The [Shared Infrastructure Content] is a Grouping of ICT resources that enables structural interoperability by ICT resources supporting reusing and/or sharing of data via [Computing Hosting, Networking, and Data Hosting Infrastructure], behavioural interoperability by ICT resources supporting communication via [Technology Interface]. governance interoperability by ICT resources supports also the collaboration with internal/external peers exchanging data, information or knowledge (i.e. [Technical Interoperability Agreements] on technical terms/conditions enabling provisioning/consuming back-office services cross public administrations and cross borders), and governance interoperability by ICT resources supporting collaboration via [Technical Interoperability Agreements]. The Interoperable European Solution viewpoint models the most salient Architecture Building Blocks related to the modelling of interoperable solutions across europe. Public administrations must consider all the aspects reported within the viewpoint when creating solution that should consider all the aspects specific to interoperability. Narrative: [Interoperable Digital Solution] is composed by a [Shared Platform][Machine to Machine Interface] and [Human Interface]. [Machine to Machine Interface] and [Human Interface] are assigned to the [Digital Solution Component] relised by the [Digital Solution component] and associated with the [Shared Knowledge Base]. [Interoperable Digital Solution] is regulated by a [Shared Legal Framework] and associated with [Shared Governance Framework] which is also associated with [Shared Legal Framework] and [Shared Platform]. The [Shared Legal Framework] regulates also the [Shared Platform]. The Interoperability Governance viewpoint models the most salient Architecture Building Blocks that refer to decisions on interoperability frameworks, institutional arrangements, organisational structures, roles and responsibilities, policies, agreements and other aspects of ensuring and monitoring interoperability at national and EU levels. As such, it does not include operational Architecture Building Blocks like interoperability agreements. Interoperability governance is the key to a holistic approach on interoperability, as it brings together all the instruments needed to apply it. Source: The New EIF https://ec.europa.eu/isa2/sites/isa/files/eif_brochure_final.pdf Narrative: The selected Architecture Building Blocks from the five different views highlight the Architecture Building Blocks of the EIRA that are related to Interoperability Governance: 1. The selected Architecture Building Blocks of the legal view show the [Public Policy Cycle] and the [Legal Interoperability Agreement], which is a specialisation of the [Legal Agreement], 2. The selected Architecture Building Blocks of the organisational view show that [Data Owner] signs [Organisational Agreement] which is a specialisation of the [Organisational Interoperability Agreement] and is composed by the [Framework Agreement] that is a specialisation of the [Specific Agreement] associated with [Means for Public Policy Objectives Convergence assurance]. The [Interoperability Strategy] implements the [Interoperability Framework], which influences the [Security Framework], the [Privacy Framework], the [Interoperable skill] and the [Interoperability governance]. The [Interoperability Governance] is under the responsibility of the [Interoperability Organisational Authority]. [Delegation of powers provisioning Digital Public Services] influences the [Interoperable Digital Public Service Implementation Orientation] which is realised by the [Digitalisation Roadmap] that realises also the [Digital Agenda], that serves the [Interoperability Strategy]. [Digital Agenda] is associated with [Digital Governance], which, in turn, is associated with [Interoperability Framework], [Security Framework] and [Privacy Framework]. 3. The selected Architecture Building Block of the semantic view show that [Data Policy] and its specialisation [Descriptive Metadata Policy], [Data Portability Policy], [Open Data Policy], [Master Data Policy], [Base Registry Data Policy] and [Reference Data Policy], together with the [Semantic Interoperability Agreement] are the mainstream of the solution governance at semantic level. Within the [Semantic governance Content] it is also considered that the [Semantic Interoperabilty Agreement] is a specialisation of a [Semantic Agreement]. 4. The selected Architecture Building Blocks of the technical view show [Technical Interoperability Agreement], which is a specialisation of the [Technical Agreement], which are the mainspring of the solution governance at technical level. The Semantic view models the most salient Architecture Building Blocks that should be considered to support semantic aspects for the End-to-End design of interoperable Digital Public Services. Narrative: [Data] is serialised using [Data Representation] the treatment and contextualisation, drives [Data] and [Data Representation] into [Knowledge]. [Data] can be grouped into [Dataset], as [Dataset] aggregates [Data]. and can be described and aggregated in [Dataset Catalogue]. [Data] is linked to [Ontology], which can be described and aggregated into [Ontologies Catalogue]. [Data Mapping] aggregates [Data] and is described and aggregated into [Data Mapping Catalogue]. [Data Mapping] is also specialised in [Metadata Catalogue], [Data Syntax Mapping Catalogue], and [Software Components Catalogue]. [Distributed Ledger] is associated to [Data] supporting the sharing and recording of encrypted data across multiple sites, countries, or institutions. [Virtual Dataset] aggregates [Dataset], that can be specialised in [Reference Data] and [Master Data]. [Base Registry] is composed of [Master Data]. [Data] can be represented as [Linked Data] and [Open Data], which are specialisations of [Data]. The representation [Linked Open Data] is a specialisation of both [Open Data] and [Linked Data]. [Linked Data] can be distributed by [Linked Open Event Stream], which is a specialisation of it. [Hash Code] and [Metadata] specialise [Data]. [Metadata] is at the same time, specialised by [Data Model], which is composed of [Forms Structure] and [Data Format], and aggregates [Data Syntax]. [Controlled Vocabulary] is a specialisation of [Data Model]. [Data] has a specific [Data Owner] that is responsible for its management, together with [Digital Public Service Delivery Consumer] and [Digital Public Service Delivery Provider Provider] and all negotiate and reach a [Semantic Agreement] and/or a [Semantic Interoperability Agreement], which is a specialisation of [Semantic Agreement]. [Data] is subject to [Data Policy], which has specific cases that are [Master Data Policy], [Security Policy], [Privacy Policy], [Data Portability Policy], and [Open Data Policy]. These different Architecture Building Blocks define the [Semantic Functional content] and [Semantic Governance Content], both are aggregated with [Semantic Knowledge Content]. Why is it a Facility? Where is Location? The Technical Infrastructure view models the most salient cross-sectorial infrastructure services that need to be considered to support technical aspects for the infrastructure (i.e. computing hosting, networking, and data hosting) for the End-to-End design of interoperable Digital Public Services. Narrative: In the same way, as it happens in the Technical Application view, the [Technical Governance Content], the [Technical Agreement], and its specialisations [Tech Interoperability Agreement] and [Service Level Agreement] constitute the [Technical Governance Content] and influence the whole [Technical Infrastructure Functional Content]. Both, [Technical Governance Content] and [Technical Infrastructure Functional Content] are aggregated by the [Shared Infrastructure Content]. The infrastructure is located in a [Facility Location] and hosted using a [Hosting Facility]. [Hosting Facility] is realised by [Computing Hosting, Networking and Data Hosting Infrastructure]. The capabilities of a [Hosting Facility] are supported by a set of physical (in place) elements: [Physical Computing Infrastructure], [Physical Network Infrastructure], [Physical Communication Infrastructure], [Physical Power Supply Infrastructure] and [Physical Security Infrastructure]. [Analytics Infrastructure Enablers] aggregates [Analytics Technology Service], [Business Intelligence Technology Service], [Databricks Technology Service], and [Data Catalog Technology Service]. The [Artificial Intelligence infrastructure Enablers] aggregates [Machine Learning Technology Service]. [Digital Workplace Infrastructure Enablers] aggregates [Remote Desktop Technology Service]. [Management Infrastructure Enablers] includes four elements aggregated [Logger Technology Service], [Audit Manager Technology Service], [Telemetry Technology Service] and [Management Console Technology Service]. [Application Integration Infrastructure Enablers] aggregates a set of technology services to facilitate integration in organisations and are [Enterprise Service Bus Technology Service], [Event Manager Technology Service], [API Manager Technology Service], which is aggregated by an [API Gateway Technology Service], also [Serverless Orchestrator Technology Service], [GraphQL Server Technology Service] and [Application Service]. [Content Delivery Infrastructure Enablers] aggregates [Web Server Technology Service] and [Streaming Server Technology Service]. [Process Orchestration Infrastructure Enablers] aggregates [Business Process Manager Technology Service]. The [Database Infrastructure Enablers] aggregates [Relational Database Manager Technology Service], [Object-Oriented Database Manager Technology Service], [NoSQL Database Manager Technology Service], [Graph Database Manager Technology Service], and [Database Cache Manager Technology Service]. [Storage Infrastructure Enablers] aggregates [File Storage Technology Service], [Block Storage Technology Service], [Backup Technology Service], and [Distributed File System Technology Service]. [Data Lake Infrastructure Enablers] aggregates [Data Lake Storage Technology Service]. The [Identity and Access Infrastructure Enablers] aggregates [Identity Provider Technology Service], [Federated Identity Provider Technology Service], and [Lightweight Directory Access Technology Service]. [Trust Infrastructure Enablers] aggregates [PKI Certificate Manager Technology Service]. [Blockchain Infrastructure Enablers] aggregates [Inmutable Database Manager Technology Service], [Blockchain Ledger Technology Service], and [Distributed Blockchain Network Technology Service]. [Containers Infrastructure Enablers] aggregates [Container Orchestrator Technology Service] is aggregated by [Containers Manager Technology Service], which is associated to [Container Registry Technology Service], and [Container]. [Networking Infrastructure Enablers] aggregates [Virtual Private Network Technology Service], [Gateway Technology Service], [Domain Name Service Technology Service], and a [Router Technology Service] associated to a [Private Network], composed by a [Private Subnetwork], associated to [Firewall], which is associated to [Load Balancer Technology Service]. [Computing Infrastructure Enablers] is composed with [Virtual Machine] node. [Virtual Machine] specialise a [Server] node. [On Premise Facility] and [Cloud Computing Facility] specialise [Computing Hosting, Networking and Data Hosting Infrastructure]. [On Premise Facility] includes [Local Area Network]. [Cloud Computing Facility] is associated with [SaaS], which is composed of [PaaS], and [PaaS] is composed of [IaaS]. The [IaaS] includes [Cloud Private Network]. [Hybrid Cloud Facility] and [Edge Computing] aggregate both [On Premise Facility], and [Cloud Computing Facility]. Also, [On Premise Facility] and [Cloud Computing Facility] are served by [Wide Area Networking], which aggregates [Secure Public Network], specialised by [Public Network]. [Additional Area Networking] includes several associations that can be established with external services, facilities or devices, for instance [External Facility], [External Service], [Desktop Computer], [Smart Device], [Sensor], [Remote Desktop Client]. These different Architecture Building Blocks define the [Technical Infrastructure Functional content] and [Technical Governance content]. Change the example The Technical Application view models the most salient application Architecture Building Blocks that need to be considered to support technical aspects for the End-to-End design of interoperable Digital Public Services. Narrative: [Interoperable Digital Solution] aggregates [Shared Platform], and provides access to data and services. The [Interoperable Digital Solution] includes [Machine to Machine Interface] with [Human Interface], which both realise [Digital Public Service Delivery], which assign [Digital Public Service], which realize [Digital Business Capability]. Also [Machine to Machine Interface] and [Human Interface] assign [Digital Solution Service] which is realised by [Digital Solution Component]. [Interoperable Digital Solution] is influenced by [Technical Agreement], and its specialisation [Tech Interoperability Agreement] and [Service Level Agreement], all three elements constitute [Technical Governance Content]. [Shared Platform] includes [API Enablers] to register the system services in which [Web Service] which is a specialisation of [API], as well as [Machine to Machine Interface]. [API Catalogue Component] realises [API Discovery and Catalogue Service] which associate with [API Catalogue] which associate with [API]. [Service Registry] is associate with (is a) [Web Service] and [Service Discovery and Registry Service] which realized by [Service Registry Component]. Orchestration Enablers in which [Orchestration Component] realises [Orchestration Service]. Security Enablers in which [Audit Component] realises [Audit Service]. [Security Enablers] include a subset of Identification and Access Enablers where [Identification Component] realises [Authentication Service], [Request Validation Service], [Registration Service], and [Access Management Component] realises [Access Management Service] and its specialisations [Identity Management Service], [Authorisation Service], and the [Accounting Service]. [Test Enablers] in which [Conformance Testing Component] accesses [Conformance Test Scenario] and performs [Conformance Testing Service]. Trust between systems is established with Identity management is realised with [Trust Enablers] in which [Trust Service Provisioning Component] realises [e-Signature Creation Service],[e-signature Verification and Validation Service],[e-signature Preservation Service], [e-Seal Creation Service], [e-Seal Verification and Validation Service], [e-Seal Preservation Service], [e-Timestamp Creation Service], [e-Timestamp Verification and Validation Service], [Registered Electronic Delivery Service] and [Integrity Verification Service]. Also [Blockchain Component] realises [Blockchain Service]. In [Data Exchange Enablers] exist [Data Exchange Component] which realises [Data Exchange Service]. In [Data Management Enablers] exist the [Metadata Management Component] realises [Metadata Management Service]. [e-Archiving Component] realises [e-Archiving Service]. [Data Management Component] realises [Data Management Service]. [Forms Management Component] realises [Content Management Service] and [Forms Management Service]. [Data Publication Component] realises [Data Publication Service]. [Data Extraction, Transformation, and Loading Component] realises [Data Extraction, Transformation, and Loading Service]. [Data Quality Component] realises [Data Quality Service]. [Data Persistence Component] realises [Data Persistence Service]. There is also the [Data Virtualization Component] that realises [Data Virtualization Service]. In [Privacy Enablers] exists the [Privacy Component], which realises the [Privacy Service]. In [Knowledge Discovery Enablers] the [Knowledge Discovery Component] realises [Knowledge Discovery Component Service] which is associated with [Knowledge Triple stone]. In [Analytics Enablers] [Data Analytics Component] realises [Data Analytics Service]. In [Artificial Intelligence] the [Artificial Intelligent Component] realises [Artificial Intelligent Service]. [Translation Enablers] enable the possibility to increase the accessibility to public service through [Machine Translation Component] that realises [Machine Translation Service]. In [Users Experience Management Enablers] the [Public Administration Single Window Component] realises [Public Administration Single Window Service]. In [Digital Workplace Enablers] exist [Digital Workplace Component] which realises [Digital Workplace Service]. In [Schedule Management Enablers] the [Schedule Management Component] realises [Schedule Management Service], and the [Agenda Management Component] realises [Agenda Management Service], which is a specialisation of [Schedule Management Service]. The [Data Space Enablers] includes the [Data Space] which aggregates [Data Space Connector], and it has two specialisations, which are the [Data Space Connector Provider] and [Data Space Connector Consumer]. These different Architecture Building Blocks define the [Technical Application Functional content] and [Technical Application Governance content] The Legal view models the most salient public policy development enablers and implementation instruments that shall be considered to support the End-to-End design of interoperable digital public services. Narrative: A [Public Policy] aims at addressing the needs of a group of stakeholders, and it is associated with a [Public Policy Objective]. The policy is formulated and realized with the help of [Legal Act] which has two specializations [European Legal Act] and [National Legal Act] in the form of [Binding Instrument] or [Non-Binding Instrument]. A key type of legislation for behavioural interoperability is the [Legislation on Data Information and Knowledge Exchange], which is a specialization of a legal key enabler for the delivery of digital public services, the [Legislation on Digital Public Services]. Both are contained in [Legislation Catalogue], as they are specialisations. [Legislation Catalogue] include [Legal Act] and the different specialisations [European Legal Act] and [National Legal Act], and the different forms [Binding Instrument], and [Non-Binding Instrument]. The [Legal act] aggregates [Legal Clauses] and is realised by [Public Policy] and linked to the [Granularity of Legal Requirements]. [Public Policy] realises [Digital-ready Policymaking], and the same time [Public Policy Constraint] which is a specialisation of a [Public Policy Context] realises the [Public Policy]. [Public Policy] has associated a [Public Policy Objective] and [Delegation of Powers Provisioning Digital Public Services], which influences [Public Policy Context]. As part of the Legal Governance Content, [Legal Agreement] is specialised by [Legal Interoperability Agreement] focused on formalizing governance rules enabling collaboration between digital public services. [Legal Interoperability Agreement] can be reached at the European level [European Legal Interoperability Agreement] or the National level [National Legal Interoperability Agreement]. These different Architecture Building Blocks define the [Legal Governance Content] and the [Legal Functional Content], which both are aggregated by [Shared Legal Content]. The Organisational view models the most salient Architecture Building Blocks that shall be considered to support organisational aspects for the End-to-End design of Digital Public Services. Narrative: [Digital Public Service] is delivered according to its [Digital Public Service Delivery Model] and realises a [Digital Business Capability] by accessing [Information]. [Digital Public Service] is documented in [Digital Public Service Catalogue] that can be used among others with services portfolio management purposes. The [Digital Public Service Catalogue] aggregates the [Shared Organisational Content] as the [Organisational Agreement] and the [Digital Public Service Delivery Model]. [Digital Public Service Delivery Model] assigns/aggregates [Digital Public Service Delivery Machine Agent] and [Digital Public Service Delivery Human Agent] both serving a role [Agent]. [Agent] is specialised by stakeholders [Individual] and [Legal Entity], which is the specialisation of another stakeholder [Organisation]. [Organisation] is also specialised by stakeholders such as [Business] and [Public Administration]. An [Agent] can serve both relations, as [Digital Public Service Consumer] and [Digital Public Service Provider]. Both roles are assigned with the business function [Digital Public Service Provision]. [Organisational Agreement], which is specialised in [Organisational Interoperability Agreement]. [Digital Governance Plan] is composed by contracts [Agreement on Provision of Digital Public Services], [Agreement on Interoperability Security] which is associated to [Security Framework], the [Agreement on Privacy] associated to [Privacy Framework], the [Agreement on Data Sharing] and [Agreement of the Use on Common Infrastructure] both associated to [Interoperability Framework]. [Digital Governance Plan] realises the [Digital Agenda] that influences the [Interoperability Strategy]. [Digital Agenda] is realised by a [Digitalisation Roadmap], which developing the constraint [Interoperable Digital Public Service Implementation Orientation]. [Data Owner] is a business role that signs or agrees upon [Organisational Agreement] that realises the constraint [Means for Public Policy Objectives Convergence Assurance and Control]. On the delivery of the [Digital Public Service] a [Digital Public Service Delivery] business interface is assigned to the [Digital Public Service], and the business interface can have different modalities such as [Web App], [Mobile App], [Desktop App], [Service App], and [Adaptive Configuration]. These different Architecture Building Blocks define the [Organisational Governance content] and [Organisational Functional content], both aggregated with [Shared Organisational Content]. Each of these Architecture Building Blocks can have any [Interoperability Specification] associated, which is realised by a [Solution Building Block]. DESCRIPTION: [Analysis of a target digital public solution] groups the following ABBs: [Interoperability Dimension] which is associated with the [EIRA Architecture Building Blocks] requirement. the [EIRA Architecture Building Blocks] composes the [EIRA View], which is associated with the [EIF Interoperability Level], aggregates the [EIRA Viewpoint] and is a specialization of the [Key Interoperability Enabler] and [Architecture Building Block] which in turn adds granularity to the [Detail - level Architecture Requirement]. The [Detail - level Architecture Requirement] is a specialist ion of the [Interoperability Requirement] which aggregates all the [Interoperability Aspects]. [Analysis of a target digital public solution] is influenced by [Architecture Principle] which is a specialization of the [EIF Principle] and aggregates the [European Library of Architecture Principle]. [Architecture Principle] influences also the [Solution design of a target digital public service / Documentation of an existing digital public service] which is composed by the [EIRA Solution Building Block] that realizes the [Interoperability Specification] and specializes the [Solution Building Block] that, in turn, is composed by the [Digital Solution] which realizes the [Interoperable Digital Solution]. The [Solution Building Block] realizes the [Solution Specification] that is a specialization of the [Interoperability Specification] which aggregates the [EIRA Library of Interoperability Specifications]. This file provides the ArchiMate model of the European Interoperability Reference Architecture (EIRA). The EIRA has been developed in the context of Action of the Interoperability Solutions for European Public Administrations (ISA2) Programme. The EIRA is a reference architecture focused on the End to End design of interoperable digital public service. It is composed of the most important architecture building blocks needed for the delivery of digital public services, realise digital business capabilties for public administrations and promote cross-border and cross-sector interactions between public administrations. The EIRA is a Service Oriented Architecture and uses ArchiMate as a modelling notation. The EIRA implements the New European Interoperability Framework (EIF). The latest release of the EIRA is available on Joinup: https://joinup.ec.europa.eu/asset/eia/description The latest release of the new EIF is available here: https://ec.europa.eu/isa2/eif_en