Recommendation 10

Recommendation 10: Adopt a common architecture to develop digital government solutions, facilitating the integration of geospatial requirements

Why:

  • Adopting a common interoperability framework and reference architecture ensures that interoperability is addressed, especially when there is the intention to reuse existing solutions. In this respect, the European Interoperability Framework (EIF) and the associated European Interoperability Reference Architecture (EIRA) define interoperability in a holistic manner, by taking into account all relevant layers: legal, organisational, semantic and technical
  • The lack of a common architecture and common terminology on location information can lead to divergent and difficult-to-integrate location information systems. INSPIRE provides a common architectural approach for cross-sector and cross-border digital government solutions involving location information
  • Service-oriented architecture provides flexibility, modularity, scalability, improved information flow and encourages re-usability of services
  • The EIRA implements the four interoperability layers of the EIF and provides further scoping, common terminology and re-usable architecture building blocks to develop service-oriented architectures and services. By using a common terminology, it will be easier for public administrations to integrate location information when developing digital public services. Common terminologies permit minimum level of coordination by providing a set of well-defined architecture building blocks
  • The “EULF Architecture and Standards for SDI and e-Government” report complements the EIF and the EIRA and provides additional information on how they relate to each other and how INSPIRE fits into the overall architectural framework

How:

Find detailed guidance on architectures and standards for SDIs and e-Government location enabled e-Government Services with the Guidelines on Architectures and Standards for SDIs and e-Government

  • Design the architecture of the digital public service by taking into account the four interoperability layers defined by the European Interoperability Framework (EIF): legal, organisational, semantic, and technical. The EIF also provides underlying architectural principles to consider when designing the service-oriented architecture (SOA). These principles should be applied when defining the architecture of the location-enabled digital public service
  • Consider adopting ‘Government as a Platform’ (GaaP) approaches to share components, service designs, platforms, data and hosting across public authorities, enabling location data and services to be reused as effectively and widely as possible
  • Use an approach based on Service-Oriented Architecture (SOA) for web services such as those specified within INSPIRE. SOA enables a system of building blocks and ensures re-usability, modularity and flexibility of the service
  • Align with evolving technologies in digital government as shown in Figure 9
  • Consider deploying a Meshed App and Service Architecture (MASA) approach. This is a new application architecture structure with constituent parts (apps, mini services, micro services and mediated Application Programme Interfaces (APIs)) which delivers increased agility and enables application innovations to support Internet of Things (IoT) integration, automated decision making, third-party interoperability and omni-channel business models. A mediated API is a design pattern in which an API is virtualised, managed, protected and enriched by a mediation layer. This layer can enforce policy and inject capabilities into the API interaction for increased agility, usability, performance, security and control. A mediated API allows a service to expose an "inner API" that directly reflects its domain model, and one or more "outer APIs" tailored to support specific client requirements. Organisations adopting SOA, MASA and these transformative architecture patterns can take advantage of a number of transformative business innovations, the API economy. An API marketplace is an aggregator site in which API providers can publish APIs that provide access to their services, data or applications. Customers use an API marketplace to discover, access, test and purchase access to APIs to use in their own applications. API marketplaces differ from standard API developer portals by aggregating multiple API providers and by providing subscriptions, billing and user management. Essentially, what app stores are for mobile apps, API marketplaces are for APIs
  • Use the European Interoperability Reference Architecture (EIRA), a content meta-model and reference architecture focused on interoperability between public administrations. The EIRA expands on the interoperability levels of the EIF. It provides architecture building blocks for each layer together with a common terminology. Furthermore, it uses a SOA-based approach in-line with the EIF
  • Consult the EULF Architecture and Standards for SDI and e-Government document. This documents uses the Reference Model for Open and Distributed Processing (RM-ODP) to describe architecture and standards for Spatial Data Infrastructure (SDI) and digital government. It provides information on how digital public services relate to assets from SDIs and INSPIRE
  • Use a recognised common modelling language such as Archimate, an open and independent modelling language for enterprise architecture that is supported by different tool vendors

Note:
  • The recommendations above provide examples of architecture approaches and methodologies. Other relevant architecture frameworks and methodologies can be used in combination with the EIF and EIRA such as: TOGAF, DYA, GERAM, Nolan-Norton or Zachman’s framework

Challenges:

  • The application may be (largely) standalone and considerations of wider architectural conformity may be an overhead
  • Different public administrations may have different architectural standards making cross-administration interoperability difficult, particularly in a cross-border context
  • Integration may be required with legacy systems that were not built using today’s architectural principles
  • The EIRA and EIC are not yet fully proven and embedded in EU-wide architectural planning for digital government systems
  • More amenable people and administrations might share their solutions but these might not be the best solutions

Best Practices:

Further reading:

Nature of documentation: Technical report

Categorisation

Type of document
Document
Licence
European Union Public License, Version 1.1 or later (EUPL) 
Login or create an account to comment.