The European Interoperability Reference Architecture (EIRA) is a framework that’s transforming the way organizations connect and collaborate in the digital age. EIRA provides a common structure and terminology for ICT solutions, making it easier for different systems and organizations to work together seamlessly.
The inGOV project leverages both the EIRA framework and the inGOV Holistic Framework into a combined approach to achieve interoperability using co-creation. To this end, core guidelines of the Holistic Framework have been incorporated into the relevant EIF-derived architecture principles of EIRA to enforce that co-creation is omnipresent in all aspects of architecture design. Specifically, a new principle supplementing the EIF Architecture principle was proposed (recommended extensions by inGOV in bold):
It is a requirement of the lowest possible level of granularity providing agreed by the whole spectrum of affected stakeholders’ orientation i) to analyse European public services by driving the identification and formulation of interoperability requirements with higher levels of granularity, ii) to design European public services by driving the identification and formulation of interoperability specifications and iii) to ensure that value-creation was identified using co-creation
As this principle is used for the definition of all Architecture Building Blocks (ABB) and subsequently for the instantiation into Solution Building Blocks (SBB), it encompasses the whole design process of the architecture.

Furthermore, by incorporating the Holistic Framework into the Architecture Development Method (ADM) cycles of TOGAF, inGOV provided a methodology involving co-creation not only in the design and implementation phases of an interoperable solution but also at the initial stages of needs elicitation and value creation. Citizens and organisations are thus not only involved in how an interoperable Egov solution will be implemented but also in what the solution will provide.

The way each ADM phase of TOGAF was implemented using the Holistic Framework, is described in the following list:

Preliminary phase – Framework and principles
Starting from the needs elicitation phase, each unit within each pilot (e.g., individual teams) was identified, and there was an effort to create the requirements collaboratively via regular and on-demand telcos and workshops with each team for each one of the pilots performed incremental changes using sprints as needed. The enterprise teams for each pilot were thus formed during the initial collaborative process of needs elicitation.

Phase A – Define the architectural vision
In inGOV, we made sure that the vision was well-defined in each design and implementation iteration. Especially in the first iteration, there was a strong effort to gather requirements and discuss them with the pilots before any major design decisions were made.

Phase B through D – Define the Business, the System and the Technical Architecture
Each Architecture Building Block (ABB) and/or Solution Building Block (SBB) for any of the layers of the EIRA-compliant architecture was defined in collaboration with the pilots and stakeholders and refined as needed. By the time of the final iteration, most of these blocks had been finalized.

Phase E- Identification of new opportunities
While in inGOV the pilot cases had definite objectives from the start of the project (as laid out in the needs elicitation phase), co-creation, mostly at the level of value-creation, led to the discovery of new functionality that could benefit the organisations. Examples are the inclusion of Knowledge Graphs to represent the public services structure and interconnection in the case of the city of Bjelovar, or the need to incorporate a blockchain-based solution for transparency and provenance regarding the payment of accommodation city taxes in the case of NOEL

Phase F – Migration Planning
While it was not essential for inGOV, some of the benefits of incorporating principles of the inGOV Framework in this phase could be extrapolated, especially on the aspects of the cost evaluation from the organisation stakeholders and the benefits of migration from the end-user stakeholders.

Phase G – Governance
Incremental changes to the architecture were always implemented using co-creation with the stakeholders, while for the major revisions, the implementation phase was programmed to take place in parallel with pilot activities conducted in WorkPackage 4 involving external stakeholders and end-users.

Phase H – Architecture Maintenance Management
Following the principles of the Holistic Framework, maintenance and reassurance that the architecture still delivers the benefits promised should take place by collecting end-user feedback.

In summary, while the process of incorporating the Holistic Framework into the architecture design and implementation process has definitely added overhead in time and resources, especially in the initial phases, it can be surmised by the results of the project that this addition led to an overall improvement in efficiency, as the reduced need of redesign and refactoring more than compensated for the initial overhead. Moreover, the end result incorporated value created by the end-users; this means that additional needed functionality was implemented, thereby both increasing satisfaction levels of end users and reducing the overall cost of having to add this needed functionality to future projects or releases. The lessons learnt from this process, have been described in the present item and have been incorporated as suggestions for extensions to existing standards, with the aim of helping agile teams to include the Holistic Framework in their design and development cycles.