Documents the result of verifying the behavior or output of one or more tests It is making a conformance or interoperability assessment and is generally intended for human readers. Based on CEN/CENELC GITB https://www.cen.eu/work/areas/ict/ebusiness/pages/ws-gitb.aspx Technical interoperability means the ability of two or more information and communication technology applications, to accept data from each other and perform a given task in an appropriate and satisfactory manner without the need for extra operator intervention. Technical interoperability specifications support technical interoperability, at the application level, by addressing the core technical application interoperability background for solutions. Technical interoperability specifications support technical interoperability, at the infrastructure level, by addressing the core technical infrastructure 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 A Test Scenario is an abstract definition of the testing process to perform a specific set of validations needed to perform conformance or interoperability testing based on a specification. Source: CEN/CENELC GITB https://www.cen.eu/work/areas/ict/ebusiness/pages/ws-gitb.aspx Technical interoperability means the ability of two or more information and communication technology applications, to accept data from each other and perform a given task in an appropriate and satisfactory manner without the need for extra operator intervention. Technical interoperability specifications support technical interoperability, at the application level, by addressing the core technical application interoperability background for solutions. Technical interoperability specifications support technical interoperability, at the infrastructure level, by addressing the core technical infrastructure 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 Technical interoperability means the ability of two or more information and communication technology applications, to accept data from each other and perform a given task in an appropriate and satisfactory manner without the need for extra operator intervention. Technical interoperability specifications support technical interoperability, at the application level, by addressing the core technical application interoperability background for solutions. Technical interoperability specifications support technical interoperability, at the infrastructure level, by addressing the core technical infrastructure 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 Technical interoperability means the ability of two or more information and communication technology applications, to accept data from each other and perform a given task in an appropriate and satisfactory manner without the need for extra operator intervention. Technical interoperability specifications support technical interoperability, at the application level, by addressing the core technical application interoperability background for solutions. Technical interoperability specifications support technical interoperability, at the infrastructure level, by addressing the core technical infrastructure 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 Technical interoperability means the ability of two or more information and communication technology applications, to accept data from each other and perform a given task in an appropriate and satisfactory manner without the need for extra operator intervention. Technical interoperability specifications support technical interoperability, at the application level, by addressing the core technical application interoperability background for solutions. Technical interoperability specifications support technical interoperability, at the infrastructure level, by addressing the core technical infrastructure 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 Technical interoperability means the ability of two or more information and communication technology applications, to accept data from each other and perform a given task in an appropriate and satisfactory manner without the need for extra operator intervention. Technical interoperability specifications support technical interoperability, at the application level, by addressing the core technical application interoperability background for solutions. Technical interoperability specifications support technical interoperability, at the infrastructure level, by addressing the core technical infrastructure 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 Technical interoperability means the ability of two or more information and communication technology applications, to accept data from each other and perform a given task in an appropriate and satisfactory manner without the need for extra operator intervention. Technical interoperability specifications support technical interoperability, at the application level, by addressing the core technical application interoperability background for solutions. Technical interoperability specifications support technical interoperability, at the infrastructure level, by addressing the core technical infrastructure 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 A Representation is the perceptible form of information carried by a business object. Source: ArchiMate http://pubs.opengroup.org/architecture/archimate3-doc/chap08.html Public Administration means 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 to provide public services, when acting under such a mandate. Source: Connecting Europe Facility (CEF), eIDAS regulation https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/CEF+Definitions 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. A Public Service is a mandatory or discretionary set of acts performed, or able to be performed, by or on behalf of a public organisation. Services may be for the benefit of an individual, a business, or other public authority, or groups of any of these. The capacity to act exists whether it is used or not, and the term 'benefit' may apply in the sense of enabling the fulfilment of an obligation. As defined in the revised version of the European Interoperability Framework, a European public service comprises any service provided by public administrations in Europe, or by other organisations on their behalf, to businesses, citizens or others public administrations. Public service – activities that public authorities identify as being of particular importance to citizens (A2C), businesses (A2B) and public administrations (A2A) and that would not be supplied (or would be supplied under different conditions) if there was no public intervention. 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 Any natural or legal person or public entity or group of such persons and/or bodies which offers the execution of public services. Based on IATE definition (definition of service producer, entry Economics, Taxation [Council]) http://iate.europa.eu/ Interoperability Agreements are concrete and binding documents which set out the precise obligations of two parties cooperating across an ‘interface’ to achieve interoperability. An Interoperability Agreement is the means through which organisations (public administrations, or businesses) formalises the cooperation with one another. These agreements aim at the development of interoperability solutions, which meets the functional / technical requirements and needs of one another. [European Interoperability Framework] Source ISA2, EIFv2 https://ec.europa.eu/isa2/isa2_en 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). Way of delivering to public service consumers, or otherwise interacting with them, for the purpose of supplying specific public services. 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. Based on the definitions in Innovation Policy Platform (World Bank and OECD) and ITIL https://www.innovationpolicyplatform.org/printpdf/12406 https://www.itil-itsm-world.com/delivery.htm Any natural or legal person or public entity or group of such persons and/or bodies which offers the execution of public services. Based on IATE definition (definition of service producer, entry Economics, Taxation [Council]) http://iate.europa.eu/ A business capability is 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 A business capability is 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 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. A Public Service is a mandatory or discretionary set of acts performed, or able to be performed, by or on behalf of a public organisation. Services may be for the benefit of an individual, a business, or other public authority, or groups of any of these. The capacity to act exists whether it is used or not, and the term 'benefit' may apply in the sense of enabling the fulfilment of an obligation. As defined in the revised version of the European Interoperability Framework, a European public service comprises any service provided by public administrations in Europe, or by other organisations on their behalf, to businesses, citizens or others public administrations. Public service – activities that public authorities identify as being of particular importance to citizens (A2C), businesses (A2B) and public administrations (A2A) and that would not be supplied (or would be supplied under different conditions) if there was no public intervention. 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 Any natural or legal person or public entity or group of such persons and/or bodies that receives or uses a public service. Based on IATE (definition of service consumer, entry Preparation for market, ECONOMICS [COM]) http://iate.europa.eu/ Represents the business facts, data, or opinions, in any medium or form, including textual, numerical, graphic, cartographic, narrative, or audio-visual forms that the capability exchanges with other capabilities to support the execution of value streams. Examples include information about public service consumers, products and services, policies and rules, reports and metrics. Based on TOGAF guide about business capabilities and TOGAF definition of information. https://www2.opengroup.org/ogsys/catalog/g161 http://pubs.opengroup.org/architecture/togaf9-doc/arch/ A business capability is 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 Communication of business information by a business capability. Based on TOGAF definitions. https://www2.opengroup.org/ogsys/catalog/g161 http://pubs.opengroup.org/architecture/togaf9-doc/arch/ Communication of business information by a business capability. Based on TOGAF definitions. https://www2.opengroup.org/ogsys/catalog/g161 http://pubs.opengroup.org/architecture/togaf9-doc/arch/ An action taken by a public authority to bring about social change in the medium and long term. It 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. Source: Eurovoc 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 The policies; overview of EU activities in all areas, from agriculture to transport: http://ec.europa.eu/policies/index_en.htm 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. Based on NCPI (partnership among Stanford and other universities) 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 Legal requirements : Any legal demands, constraints, needs needed to be met. Legal constraint : Legal limitation. Based on the Black's Law Dictionary http://thelawdictionary.org/requirements/ http://thelawdictionary.org/constraint/ http://thelawdictionary.org/restraint/ Binding instrument: legal means, involving an obligation, which is available to the European institutions to carry out their tasks. 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. Based on EUR-Lex and the Oxford dictionary definition of binding http://eur-lex.europa.eu/summary/glossary/community_legal_instruments.html https://en.oxforddictionaries.com/definition/binding Business rules represent 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/ Binding instrument: legal means, involving an obligation, which is available to the European institutions to carry out their tasks. 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. Based on EUR-Lex and the Oxford dictionary definition of binding http://eur-lex.europa.eu/summary/glossary/community_legal_instruments.html https://en.oxforddictionaries.com/definition/binding Binding instrument: legal means, involving an obligation, which is available to the European institutions to carry out their tasks. 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. Based on EUR-Lex and the Oxford dictionary definition of binding http://eur-lex.europa.eu/summary/glossary/community_legal_instruments.html https://en.oxforddictionaries.com/definition/binding A data policy is a short statement of management intent and fundamental rules governing the creation, acquisition, integrity, security, quality, and use of data and information. Source: Data Management Body Of Knowledge (DAMA DM_BOK) First edition http://www.dama.org A data policy can be among others the following: - information security policy; - privacy policy; - licensing and charging policy ; - data quality policy; and - metadata management policy. Semantic interoperability enables organisations to process information from external sources in a meaningful manner. It ensures that the precise meaning of exchanged information is understood and preserved throughout exchanges between parties. In the context of the EIF, semantic interoperability encompasses the following aspects: • Semantic interoperability is about the meaning of data elements and the relationship between them. It includes developing vocabulary to describe data exchanges, and ensures that data elements are understood in the same way by communicating parties. • Syntactic interoperability is about describing the exact format of the information to be exchanged in terms of grammar, format and schemas. Semantic interoperability specifications support semantic interoperability by addressing the core semantic 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 Technical interoperability means the ability of two or more information and communication technology applications, to accept data from each other and perform a given task in an appropriate and satisfactory manner without the need for extra operator intervention. Technical interoperability specifications support technical interoperability, at the application level, by addressing the core technical application interoperability background for solutions. Technical interoperability specifications support technical interoperability, at the infrastructure level, by addressing the core technical infrastructure 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 Interoperability Agreements are concrete and binding documents which set out the precise obligations of two parties cooperating across an ‘interface’ to achieve interoperability. An Interoperability Agreement is the means through which organisations (public administrations, or businesses) formalises the cooperation with one another. These agreements aim at the development of interoperability solutions, which meets the functional / technical requirements and needs of one another. [European Interoperability Framework] Source ISA2, EIFv2 https://ec.europa.eu/isa2/isa2_en 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). Technical interoperability means the ability of two or more information and communication technology applications, to accept data from each other and perform a given task in an appropriate and satisfactory manner without the need for extra operator intervention. Technical interoperability specifications support technical interoperability, at the application level, by addressing the core technical application interoperability background for solutions. Technical interoperability specifications support technical interoperability, at the infrastructure level, by addressing the core technical infrastructure 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 Technical interoperability means the ability of two or more information and communication technology applications, to accept data from each other and perform a given task in an appropriate and satisfactory manner without the need for extra operator intervention. Technical interoperability specifications support technical interoperability, at the application level, by addressing the core technical application interoperability background for solutions. Technical interoperability specifications support technical interoperability, at the infrastructure level, by addressing the core technical infrastructure 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 Technical interoperability means the ability of two or more information and communication technology applications, to accept data from each other and perform a given task in an appropriate and satisfactory manner without the need for extra operator intervention. Technical interoperability specifications support technical interoperability, at the application level, by addressing the core technical application interoperability background for solutions. Technical interoperability specifications support technical interoperability, at the infrastructure level, by addressing the core technical infrastructure 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 A Test Service enables the execution of interoperability and conformance testing. A Test Service is realised by one or more Test Components. A process for verifying that several solutions can interoperate at one or more layers of the interoperability stack, while conforming to one or more Specifications. This type of testing is executed by operating SUTs (System Under Test) and capturing their exchanges. The logistics of Interoperability Testing is usually more costly (time, coordination, set-up, human efforts) than Conformance Testing. Conformance does not guarantee 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. Based on CEN/CENELC GITB https://www.cen.eu/work/areas/ict/ebusiness/pages/ws-gitb.aspx A Service Discovery Service allows the automatic discovery of other services. A Service Discovery Component encapsulates the functionalities for automated service discovery. A Test Component encapsulates the functionalities for conformance and interoperability testing. A Machine to Machine Interface is a description of a boundary between a system and other systems, usually including the mechanisms by which information is transferred. [DG TAXUD] A Test Component encapsulates the functionalities for conformance and interoperability testing. Data is facts represented as text, numbers, graphics, images, sound, or video. Data is the raw material used to represent information, or from which information can be derived. Source: Data Management Body Of Knowledge (DAMA DM_BOK) First edition http://www.dama.org An Interoperable European Solution (IES) is a 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: This IES definition was derived from the Trans-European Systems definition. A Human Interface is a specific interface between the human users of an IT system and the programs providing screen or printed results. It is frequently regarded as a dedicated set of programs, separate from those which extract and process data. [DG TAXUD] A Networking Service is a service provided by a network provider. [DIGIT C Infrastructure Services Provision] A Hosting Service is a service provided by a hosting provider. [DIGIT C Infrastructure Services Provision] A Public Network is a network that can be accessed by 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. A Public Hosting Facility is a Hosting Facility which is owned by a third party and shared between organizations (e.g. cloud services). EIF Underlying principle 4: reusability Reuse means that public administrations confronted with a specific problem seek to benefit from the work of others by looking at what is available, assessing its usefulness or relevance to the problem at hand, and where appropriate, adopting solutions that have proven their value elsewhere. This requires the public administration to be open to sharing its interoperability solutions, concepts, frameworks, specifications, tools and components with others. Reusability of IT solutions (e.g. software components, Application Programming Interfaces, standards), information and data, is an enabler of interoperability and improves quality because it extends operational use, as well as saving money and time. This makes it a major contributor to the development of a digital single market in the EU. Some EU standards and specifications also exist in the DIFs and should be applied more widely. For example, the INSPIRE Directive sets out interoperability standards for addresses, cadastres, roads and many other data topics of relevance to many public administrations. These existing standards and specifications can and should be used more widely beyond the domain for which they were originally developed. Several public administrations and governments across the EU already promote sharing and reuse of IT solutions by adopting new business models, promoting the use of open source software for key ICT services and when deploying digital service infrastructure. There are some key challenges that limit the sharing and reuse of IT solutions, at technical, organisational, legal and communication levels. The ISA² sharing and reuse framework for IT solutions12 provides recommendations for public administrations to help them overcome these challenges and share/reuse common IT solutions. Reuse and sharing can be effectively supported by collaborative platforms. 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. EIF Underlying principle 10: administrative simplification Where possible, public administrations should seek to streamline and simplify their administrative processes by improving them or eliminating any 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. Likewise, public administrations should introduce European public services supported by electronic means, including their interactions with other public administrations, citizens and businesses. 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. 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. EIF Underlying principle 4: reusability Reuse means that public administrations confronted with a specific problem seek to benefit from the work of others by looking at what is available, assessing its usefulness or relevance to the problem at hand, and where appropriate, adopting solutions that have proven their value elsewhere. This requires the public administration to be open to sharing its interoperability solutions, concepts, frameworks, specifications, tools and components with others. Reusability of IT solutions (e.g. software components, Application Programming Interfaces, standards), information and data, is an enabler of interoperability and improves quality because it extends operational use, as well as saving money and time. This makes it a major contributor to the development of a digital single market in the EU. Some EU standards and specifications also exist in the DIFs and should be applied more widely. For example, the INSPIRE Directive sets out interoperability standards for addresses, cadastres, roads and many other data topics of relevance to many public administrations. These existing standards and specifications can and should be used more widely beyond the domain for which they were originally developed. Several public administrations and governments across the EU already promote sharing and reuse of IT solutions by adopting new business models, promoting the use of open source software for key ICT services and when deploying digital service infrastructure. There are some key challenges that limit the sharing and reuse of IT solutions, at technical, organisational, legal and communication levels. The ISA² sharing and reuse framework for IT solutions12 provides recommendations for public administrations to help them overcome these challenges and share/reuse common IT solutions. Reuse and sharing can be effectively supported by collaborative platforms. 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. The target solution for which this SAT is being used serves a public policy implemented by a public service with a well-defined provider and consumer. This public service is realised by one or more business capabilities that exchange business information, which is the same business information that is used in testing processes. These testing processes, pertinent to interoperability and conformance testing, are offered as a public service to the target solution’s user community. Regarding the business information used by the target solution and during testing, this is realised by data with a given representation that follow a semantic interoperability specification which is the focus of the testing activity. From a technical perspective, the key building blocks offered to the target solution are the ISA2 interoperability test bed service that exposes a web-accessible common testing platform to manage and drive the testing process, and the GITB Test Registry and Repository (TRR) through the Commission’s Joinup platform, for the discovery, sharing and reuse of test resources. The test bed service is the one that is used in the target solution to test the conformance of systems under test to a given technical specification. Finally, from an infrastructure perspective, the test bed service is hosted on the public cloud and is accessible over the internet. The ISA2 interoperability test bed service is a cross-domain service that is policy agnostic. It neither implements any specific legal instrument, nor is it mentioned or described itself in a legal text. As such, the building blocks of the Legal view shall be those related to the solution that is making use of the test bed service for its interoperability and conformance testing needs. An important point to highlight however relates to the target solution’s information security and data privacy needs. The test bed service itself offers very relaxed security considering that its goal is to be as flexible as possible allowing connections from diverse systems under test that shall exchange different types of content over non-predetermined message exchange protocols as part of the overall testing process. With relation to the exchanged test data, this is expected to be non-sensitive in nature and is recorded in order to facilitate subsequent test reporting. The target solution needs to thus take the required measures to curate appropriate test data rather than, e.g. use potentially sensitive extracts from production environments. To emphasise this point, this SAT includes two SBBs for the Legal view: - Directive (EU) 2016/1148 of the European Parliament and of the Council of 6 July 2016 concerning measures for a high common level of security of network and information systems across the Union. - Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation). These need to be considered by the target solution’s architect in order to evaluate whether it has such a legal basis regarding security and data protection, taking note that the test bed service itself has not. If the foreseen testing processes require high security (e.g. connectivity constraints that cannot be met by the test bed service) or data protection (e.g. sensitive data cannot be excluded from tests) an alternate option would be to not use the shared test bed service but rather install and manage the test bed software locally. This option is further covered in the Technical - Application View. Aside from these considerations, the Legal view ABBs foreseen by this SAT represent the key ABBs that the target solution will need to include and specify in accordance with its policy domain and legal foundation. The SAT highlights a set of ABBs on the Organisational view (presented with bright yellow in the top part of the view) that relate to the target solution. This solution in short, is expected to offer a public service that is provided by a public service provider and consumed by public service consumer, whose relation is ideally formalised using an interoperability agreement. The public service itself is realised by one or more business capabilities that include an exchange of business information. This can be considered as the core organisation-level structure that any solution is expected to have in accordance to the EIRA©. The additional ABBs and SBBs represent those related specifically to the use of the ISA2 interoperability test bed service. The public service that is enabled by the test bed is the interoperability testing for solutions that support cross-border public services. This is considered as a public service and not an internal technical detail considering that a well-defined testing platform is often expected by a solution’s user community as part of the target solution’s service offering. Typical examples would be cases where the target solution defines a semantic or technical specification that needs to be implemented by third parties to establish peer to peer connectivity or connection to a central hub. This could even extend to requiring conformance certification as a tendering prerequisite where a qualification process of third party software is involved. Definition and use of such a test-focused service serves the goals of achieving interoperability on all level as reflected in the SAT using the EIRA©’s motivation elements. The interoperability testing public service is realised through two business capabilities: conformance testing (i.e. a solution tests that it has correctly implemented a specification) and interoperability testing (i.e. two conformant solutions can interact as expected). Both these business capabilities depend upon the exchange of information as part of a testing process that makes use of the same business information that the target solution uses. As previously mentioned, it is important to highlight that the business information used for testing should not include private or sensitive information, a requirement that is reflected in the SAT as a mandatory business rule in relation to the testing process. With regards to the testing service, this is offered using a Platform-as-a-Service (PaaS) delivery model, meaning that the target solution is expected to simply use the shared test bed service rather than build it or run it itself. The test bed service is provided by DIGIT’s ISA2 Unit with which the target solution’s service provider needs to define an interoperability agreement. Regarding this, there is no fixed template available, considering that the operational model selected could vary significantly. This agreement serves primarily to define the split of responsibilities between the ISA2 test bed team and the target solution’s service provider. Points that should be covered in this include: - The responsibility in terms of implementing test scenarios and required test components (i.e. the domain-specific test artefacts), including expected support effort. If this is the responsibility of the service provider, support would be offered by ISA2 in relation to test bed specifics. If undertaken by ISA2, support would be offered by the service provider with respect to the target solution’s policy domain and business context. - The responsibility of test bed administrative tasks such as defining and managing users and test suites. - Definition of help desk responsibilities to assist users of the test bed by e.g. establishing a first-level support by the service provider for issues relative to the solution or specification itself, with second-level support by ISA2 for issues that are test bed specific. This becomes additionally important if a separate test bed instance is setup for the target solution in which case ISA2 does not have a direct operational role. - Service availability requirements for the test bed. - Training, support and consulting effort by ISA2 test bed experts provided to staff of the target solution’s service provider. - Potential use of the test bed’s hosting infrastructure to host test components related to the target solution. The ISA2 test bed service is itself not tied to specific data or representations. These are expected to be defined as part of the target solution for which the data, representation and data policy ABBs are defined in this SAT, as the focal ABBs in the EIRA©’s Semantic view. However it is important to highlight that, if the target solution requires an interoperability or conformance testing approach, there is forcibly one or more semantic or technical interoperability specifications that it defines or reuses which are key in its overall business information exchange. This is precisely the focus of the test bed and what will be supported through domain-specific test scenarios and test components. Clearly modelling these semantic and/or technical interoperability specifications is of critical importance, and is the reason why the semantic interoperability specification ABB is included in this SAT. Technical interoperability specifications are addressed in the Technical – Application view. A set of SBBs have been highlighted in this view (in bright blue) to indicate the main reusable SBBs in relation to conformance and interoperability testing. The key reusable SBB is the ISA2 test bed service that is modelled in the SAT as a test service. This represents the shared online platform that is accessed by the target solution’s user community as their testing solution, thus serving the principles of reusability and administrative simplification (modelled using the EIRA©’s motivation elements). The target solution also defines the technical specification(s) that systems under test (SUTs) need to conform to and for which the discussed testing services are needed. The test bed service is realised by means of the GITB test bed software that itself is reusable and can be installed separately as a standalone test component through an easy and well documented process . Such a separate installation could be interesting in cases where complete control over the test bed’s operation is desired or in cases where security and data privacy requirements apply also to the testing process, thus forcing the test platform to not be publicly accessible or shared with other user communities. The GITB test bed is accessible to users through a web-based user interface for the purpose of managing test suites, triggering test sessions and inspecting their reports. A further key SBB that has been highlighted in this view is the GITB Test Registry and Repository (TRR), implemented in the Commission’s Joinup platform , which acts as a service discovery service for test artefacts and services. The TRR can host test artefacts such as test cases but can also federate available test services, running from the test bed’s hosting infrastructure or from any other publicly available environment, which can be used by the interoperability testing community. These services can be, but are not limited to, GITB-compliant test services to perform validation, processing or messaging simulation as described in chapter 2.2.1, “The GITB test bed software and specifications”. The TRR is of interest for the target solution’s architecture to first help in discovering potentially reusable test resources, but also as a platform through which implemented test resources can be shared for reuse. The test bed service and underlying software act as a test-focused orchestration platform that remains generic in nature. In order to implement the domain-specific testing needs for the target solution, two elements are required: - A set of test scenarios that capture the different test cases that systems under test are expected to test against. - A set of services, implemented outside the test bed itself, to carry out complex domain-specific tasks required by the test scenarios. The test scenarios are authored in the GITB Test Description Language (GITB TDL) which is an XML-based syntax to express the key testing steps. Such steps could be the submission of content from the system under test to the test bed, its validation, a processing step to transform it, and finally the sending of an appropriate response. Such steps are represented by GITB TDL constructs for which a controlled vocabulary is also defined to facilitate the test cases’ documentation and potential reuse. Test reports produced by the test bed follow the GITB Test Reporting Language (GITB TRL), also a XML-based syntax, to capture the outcome of test sessions. Where complex domain-specific processing is required, a GITB TDL test case may call upon separate GITB-compliant services. Such services are SOAP web services that can be remote or hosted on the test bed’s infrastructure and are used for the following purposes: - Validation: This is the most common case whereby a validation service can be used to validate arbitrary domain-specific content. A common example would be a service to validate XML-based content that uses a set of XML Schema and Schematron validation artefacts. - Processing: A processing service can be used to transform input for subsequent use in the test case. An example could be a service to extract the contents from a received archive for further processing. - Messaging: This is the most complex case whereby a messaging service is used to allow the test bed to send and receive messages by means of an arbitrary communication protocol that it does not natively support. An example would be the need to send and receive content through emails, which can be driven using such a service, managed by the test bed via SOAP web service calls. The APIs for these services are specified as part of the GITB specification which defines the WSDLs for each service as well as the XML Schemas for the exchanged messages. These WSDLs, the specifications for the GITB TDL, and GITB TRL syntaxes, as well as additional specifications and supporting documentation are part of the GITB CEN Workshop Agreement specification. The information on this view is limited considering that this should reflect the infrastructure of the target solution and not the test bed service. This is more so the case considering that the test bed does not offer any Digital Service Infrastructure (DSI) components that would be additionally leveraged by the target solution. An important point to highlight however with respect to the test bed is that it is hosted on the public cloud and specifically on a public cloud hosting provider engaged through DIGIT’s Virtual Cloud Task Force. Access to the service is over the internet and open to all. The significance of these points is twofold: - The target solution’s user community can access its testing platform over the internet without need for special configurations or access to restricted networks. - Any test-related components that are to be implemented for the target solution can make use of the test bed’s hosting infrastructure. This could be an interesting option in case the target solution’s provider faces complexities in procuring additional hosting infrastructure purely for testing purposes. Note that if such a hosting arrangement is to be made, this would be an item to specify in the interoperability agreement established between the target solution’s provider and ISA2 as described in the Organisational View.