Building a Data Provider Prototype as a Student-Company Collaboration

The degree programme in Business Information Technology (BIT) provides multiple real-world projects for students every year. For the project discussed here, the Triplan Oy company had already recognized that their customers had the need for integrating their data in the company’s system with the Finna library database services. The data consist of publications and documents, for example. This article focuses on the student-company collaborative project’s outcomes and the key lessons learned throughout its duration.

Background and objective of the student-company collaboration

The company partner in this project, Triplan Oy, is a long-established supplier of information management systems for public administration, focused on developing product-based solutions for case, document, and archive management. Triplan’s systems are deployed among clients such as municipalities, cities, educational institutions, hospital districts, and central government organizations. These solutions support mission-critical processes that require high availability, data integrity, and security risk management. Technically, Triplan’s core solutions include case and document management, records management, electronic archiving, and data exposure through REST API. (Triplan, 2026)

At the beginning of the 2025 ICT Project module at HAMK, students engaged in an eight-week collaborative project with Triplan Oy, working on a real-world topic provided by the company.  Triplan had already observed a rising need among their customers to integrate their publications and documents data with Finna services. Finna is Finland’s national library, archive, and museum discovery service (Finna, n.d.). Its goal is to maximize resource discoverability through a national platform that reliably harvests metadata from sources such as Triplan’s clients. To perform this harvesting, Finna uses OAI-PMH (Open Archives Initiative Protocol for Metadata Harvesting), a standardized protocol for sharing metadata (Lagoze et al., 2002). At its core, OAI-PMH is about interactions between harvesters that collect metadata, and providers, which supply the metadata.

In this context, Finna acts as the harvester by sending standardized HTTP requests with defined parameters to retrieve metadata. The metadata must follow a specific technical format: it must be structured according to the Dublin Core schema and wrapped in XML. This strict formatting allows Finna’s systems to process and integrate new data directly into its search indexes without manual intervention.

On the provider side, Triplan must meet the minimum technical requirements of the OAI-PMH protocol to ensure seamless integration between its REST API-based system architecture  and the national Finna network, without requiring custom engineering or ongoing effort from Finna’s team. This REST-based approach reflects Triplan’s broader technical expertise and already-established system architecture, rather than a solution developed specifically for this integration. Fortunately, Triplan’s data structure already aligned well with the Finnish National Archives’ SÄHKE2 metadata model (Kansallisarkisto, 2024). However, as the data was available in JSON format rather than XML, this mismatch presented the core technical challenge – and it set the stage for the students to come up with a solution within eight weeks.

Developing and implementing a prototype of Metadata provider 

To address the identified gap between Triplan’s core systems and Finna’s harvesting requirements, the students implemented an OAI-PMH provider prototype that exposes selected metadata handled by Triplan for finna in a Finna-compatible format.

In this prototype, exposing metadata means making structured data available through a standardized OAI-PMH interface, allowing external systems such as Finna to automatically retrieve (that is, harvest) the data using the protocol’s defined operations. This approach aligns with the principles of the OAI-PMH standard, which enables interoperable metadata exchange between distributed systems. (Lagoze et al., 2002)

At the start of the project, the students had two main implementation options: either to build the solution using technologies familiar to the students, or to adapt into Triplan’s existing tech stack relying on the Spring Boot framework which helps with creating Java-based microservices and apps (Spring, n.d.). In this case, the Spring Boot approach was chosen because it ensures better hand-over, alignment with Triplan’s environment, and easier long-term maintainability.

The solution was designed as a lightweight middleware layer – that is, an application that provides services to other software applications – which retrieves structured metadata from Triplan’s existing REST API and converts it into the required Dublin Core output format. A key consideration for the developed solution was to minimise load and avoid unnecessary strain on Triplan’s source endpoints when handling API requests. The overall software architecture of OAI-PMH provider is illustrated in diagram 1 below.

The harvesting process itself follows a clear flow. First, Finna initiates the harvesting through its own OAI-PMH harvester, sending timed harvesting requests to the target systems. The provider then retrieves the corresponding metadata from Triplan’s REST API and converts it into the OAI-PMH-compliant Dublin core XML format.

To ensure that the harvesting process remains reliable and scalable even when handling large sets of metadata, the prototype includes support for pagination in the REST service through resumption tokens. These tokens allow the server to divide large result sets into smaller batches and provide a reference for retrieving the next portion of data, enabling the client to continue the harvesting process incrementally without overloading the system. Pagination implemented through resumption tokens allows Finna to request metadata in manageable batches instead of requiring all data in a single response. In addition, the prototype includes validation and error-handling methods to ensure that responses remain OAI-PMH compliant, and that incomplete data is managed in a controlled manner.

Experience of student collaboration from the company’s perspective

The Triplan Oy company initially approached this project as exploratory proof-of-concept. The company representative explained that at the start, their understanding of the technologies required for a Finna integration was limited, as they had identified a potential future need but lacked a clear implementation path. Because there was no immediate business pressure, it was possible to keep the project goal flexible. This allowed the scope of the project to be shaped dynamically to match the students’ skills while enabling Triplan to learn what an OAI-PMH–based integration would practically require.

Although this initiative was not yet driven by critical customer demand, early signals indicated that such a capability would become increasingly relevant. Therefore, the company treated this project as an investment in future readiness rather than a response to an urgent requirement. The outcome proved highly valuable: the prototype was internally reviewed by both Triplan’s product owner and software architect, and it exceeded their initial expectations by reaching a state that was close to being ready for production, instead of being just a lightweight demonstration of what could be done. The handover of the developed solution was smooth, allowing the company to continue the work further after the student project concluded.

From a technical perspective, the company did not impose strict requirements on the technology stack. Nevertheless, the end result, where the students decided to adopt Triplan’s own Spring Boot–based environment, significantly increased the value of the outcome for the company, improving both the architectural fit and its potential for reuse. As the company representative noted: “This choice demonstrated a high level of professionalism, willingness to learn, and ownership of the problem,” further explaining that the produced solution can realistically serve as a foundation for future customer cases as the demand for Finna integration becomes concrete.

In the company’s view, overall, this student collaboration was one of the smoothest Triplan has experienced. While they considered the team’s proactive approach a major factor, they also pointed out that the key to a successful project lies in managed expectations. From Triplan’s perspective, the primary value this collaboration was the opportunity for students to prove their professional capabilities and for the company to learn alongside them without immediate delivery pressure. As the company representative noted: “When the focus remains on this mutual growth, a production-quality outcome, as the one achieved here, becomes a celebrated success rather than the sole purpose of participation.”

Student experiences from the project

In the students’ view, this project combined building a practical prototype and embracing the discipline of professional software development. The students used Trunk-Based Development (Hammant, n.d.) to create small pull requests, resulting in instant feedback and fewer merge conflicts. Every feature was developed using test-driven development (TDD) which provided code that is not only reliable but remarkably low in bugs (Agile Alliance, n.d.). The team also followed agile methods in their collaboration, emphasizing iterative development, continuous feedback, and close communication between team members (Atlassian, n.d.). In addition to this, not a single change in code escaped without a sharp pair of eyes during the process. At least one team member conducted a code review of each pull request before changes were merged into the main branch. At all stages of the development phase, then, the student group created new documentation and updated existing documentation to keep everything under control and clear to the client and their development team.

From the students’ perspective, the project strengthened both technical skills and project management capabilities. It also provided a realistic view of software development in a professional environment, including focus on the importance of maintainability, scalability, and stakeholder communication. Overall, the students considered the project successful and educational, offering valuable experience for future working life.

Organising the collaboration between Triplan and HAMK

This project was made possible by the fact that the degree programmes in Business Information Technology and Computer Applications at the Häme University of Applied Science offer a 15-credit ICT Project module to third-year students who have already gained a solid background in modern technologies. Prior to the start of the module, in cooperation with companies, the degree programme prepares relevant real-world topics for student projects. Once the project topic has been selected by the students, in teams of three to five members they work on a chosen project over an eight-week period. The project discussed here was based on this process. This project in collaboration with Triplan is already the third collaboration implemented over the years.

During the project, the student team was guided both by Triplan’s representative and a supervisor from HAMK. The projects vary year-by-year in many ways, setting challenges during the whole span of the life cycle of an ICT Project. Hence, a structured but flexible collaboration model is essential. Naturally, the forms of collaboration between HAMK and Triplan in ICT projects have evolved over the years, creating an atmosphere for the students that is a trust-inspiring and safe environment for them to operate in.

The first two weeks were dedicated to intensive project planning, which includes defining requirements, conducting risk analyses, and establishing the project management framework, among other things. This project used agile methodology and in the planning phase the students prepared the initial product backlog based also on supervisor and client feedback. This was followed by two weeks of development sprints and the students also had weekly meetings together with the client and supervisor, as well as meetings with the supervisor alone. When required, the Triplan and HAMK representatives had some additional preparatory meetings without the students. The product backlog was monitored and discussed on a continuous basis to ensure that the project scope was kept suitable for the module. After each sprint, the current outcome was demonstrated to the client and who then gave feedback on the outcome.

The final week of the module was dedicated to finalizing the deliverables. In software projects, this includes refining test cases, finalizing code documentation, and compiling project reports. The depth and format of the documentation are in these types of projects always tailored to the specific needs and standards of the commissioning company to ensure a smooth hand-over. Finally, the student’s work culminated in a formal final presentation at the university, with the client in attendance.

Conclusion

Overall, this student project was the result of careful preliminary preparation by both the educational institution and the commissioning party. The scope of the project was designed with flexibility in mind, allowing for the dynamic adjustment of objectives throughout the process. Although the students were given the freedom to choose their preferred technologies, the final solution aligned naturally with the company’s established technological standards. In these types of projects, the alignment between the project topic and the students’ backgrounds is essential, as we have seen that it fosters strong intrinsic motivation that manifests as consistent dedication and a professional approach. This success is a result of the seamless, trust-based collaboration between all parties, from initial planning through to completion.

Authors