Architecture

Datamodels, Customisability, Configurability, Release management, Collaboration and cost-sharing, Multi-tenancy, Development policies, Software development kit

Intro

Today's application architecture makes Pure a customisable and agile software system, which can be navigated according to the evolving requirements faced by institutions in need of advanced research information management. In addition, Pure's architecture sustains the following particular challenges, some of which are exclusive for systems to the research- and higher education-domain:

Challenge or opportunity	Description
Datamodels	Ability to work with different datamodels
Customisability	Ability to be customisable in a number of areas according to individual customer requirements
Configurability	Customers must be able to configure a number of areas themselves.
Release management	All customers must be able to receive the frequently released upgrades to the product. It must be possible to release new versions to all customers while retaining individual customisations and configurations in customers’ instances.
Collaboration and cost-sharing	It must be possible for owners to collectively specify custom functionality and data-model modifications and it must be possible to share the costs.
Multi-tenancy	A group of owners must be able to share a single physical instance without penalties in data-disclosure, security, integrations, or business-process support.
Development policies	The ability to employ certain community policies can depend on architectural abilities
Access control	It must be possible to carefully delegate access to content.
Software Development Kit	The availability of a software development kit for 3rd party developers can be an advantage for several stakeholders.

Architectural challenges for CRIS systems

Datamodels

A number of country-specific datamodels are available. Most of these are available as standard implementations, which mean that Pure can be delivered with that datamodel out of the box. In each of these cases, the datamodel in question has been validated by one or more local HEIs and research institutions:

Datamodel	Standard	References
Belgium	Yes	1
Germany	Yes	1
Denmark (universities)	Yes	11
Denmark (UCs)	Yes	10
United Kingdom	Yes	5
Finland	Yes	1

Standardised country-specific datamodels

Each of the datamodels above can be customised according to local requirements. Usually, very little or even no customisation is needed with mature datamodels. Also, institutions often choose to go intro production with the standard model as it is, to have customisations done later when or if necessary. Having Pure delivered with a standardised datamodel is free from any additional charge.

The fact that classifications (drop-downs with fixed values) and text- resources including all field-labels and user-interface concepts are configurable by administrators reduces the need for datamodel customisation.
The Pure User group in a country is often used by Pure-owners as a forum for maintaining and extending the datamodel collaboratively in that country, especially when new national requirements must be dealt with e.g., new REF requirements in the UK, new FRIS initiatives in Belgium, etc. In such situations, the members of the national Pure User group can collectively define the changes they want, have them distributed at once to all members, and evenly share any costs that might be involved; costs for new supplementary functionality, for example.

Please also see Collaboration and cost-sharing.

Customisability

Apart from the datamodel in Pure, other areas are customisable too:
The system functionality, the User functionality, Roles and Rights, Workflows, Systems integration, Import functionality, Full-text and Repository functionality, and PurePortal-functionality are probably the most important areas, but others exist as well.

All of this customisability is rarely used within one Pure-implementation project, but it must still be available to ensure the ability of the system to adapt to future demands as well.
More information about this subject is available in the Pure4 white-paper.

Configurability

Owners of Pure can configure things like classification schemes, user-interface text, help-pages and bullets, integration jobs with internal systems, integration parameters for external sources (e.g. WoS), integration parameters for internal source (HR system, finance, etc.), validation options, public website display-options, and other things.

More information about this subject is available in the Pure4 white-paper.

Release management

Pure's architecture supports non-sequential updating. IT staff can choose to only install upgrades that contains relevant patches and additions and skip the rest: Each release will always include previous releases and make sure they are seamlessly installed.

Roughly 8-12 releases are made available per year, each of them including bug fixes, improved functionality and all-new functionality. Pure's distribution environment automatically installs new releases by the execution of a simple command. Roll-back is supported. Also, the distribution environment automatically maintains the database schema whenever new releases are installed.

Obviously, all customisations and configurations are retained when installing new releases - e.g., datamodel customisations, custom functionality, import settings, own classifications, own reports, and so on.

Collaboration and cost-sharing

While private-sector companies rarely cooperate, publicly owned research institutions and HEIs often do. When we scoped Pure4, we wanted the system to support this potential for collaboration among its owners. The result is an architectural design, which facilitates collaborative, cross-institutional customisation and cost-sharing.

A number of Pure-using universities might for example have the same requirements for certain new functionality. With Pure4, they can join, write a common specification, have Atira make the new functionality, and share the cost four ways. Such new functionality will be distributed as part of the next regular release of Pure. Only the four participating institutions will receive the new functionality.

If other institutions later wants the new functionality, it can be distributed to them too at the discretion of the original four institutions. Put differently, Pure4's architectural design allows distribution of custom functionality to a) Individual institutions, b) Groups of institutions, c) All institutions. We also refer to these distribution options as levels; the Customer level, the Base level, and the Core level. The ability for CRIS owners to collectively specify custom functionality and to share the cost introduces opportunities, which are not available with conventional enterprise-class architecture.

Please also see Development policies and business model. More information about this subject is available in the Pure4 white-paper.

Option	Level	Community
Distribute any custom functionality to any level:	Customer level	An individual institution
	Base level	A group of institutions
	Core level	All institutions

Options for distribution of customisations

Multi-tenancy

Since version 3, Pure has been able to meet most requirements for multi-tenancy. It was however not until the new architecture with Pure4, that a dedicated design-effort was made in order to ensure broad multi-tenancy support. A group of institutions can run simultaneously in a single instance of Pure without penalties in data-disclosure flexibility, security, integrations, or support of individual business-processes. Multi-tenancy is a configuration option with Pure. The following characteristics in the table below describe Pure4's multi-tenancy capabilities. More information about this subject is available in the Pure4 white-paper.

Characteristic	Description
Tenant-specific content access	When an institution is in Pure as a “tenant”, everything will look and fell as if that institution was in its own private instance of Pure - it will not see or otherwise access content of the other tenants such as Persons, Organisations, Publications, or Activities.
Tenant-specific searches	Tenants can only search in own content and not that of other tenants.
Tenant-specific reporting	Tenants can only create and run reports on own content and not on content belonging to other tenants. The same access limitations as are in an individual environment will also work in a tenancy environment within one tenant.
Tenant-specific PurePortal	A PurePortal can be set up to exhibit only content from one tenant. There can be one such tenant-specific PurePortal per tenant.
Global PurePortal	A PurePortal can be set up to exhibit content from all tenants.
Web-Service API	The Web-Service API of Pure works in the same way as in individual environments when queried without specifying any particular tenant. However, the Web-Service API can also be queried while specifying a particular tenant and will in that case return results only for that tenant.
OAI support	Pure’s OAI data-provider can make tenant-specific meta-data available per tenant, and it can make data available from all tenants in one go.
Global content types	Certain content types can be global: Publishers and Journals are practical to have globally in Pure, for example, because all tenants can benefit from them. Global content types can also be administrated globally (e.g. by librarians).
Global workflows	There can be one workflow per content type in Pure. This is also true when serving multiple tenants. However, each workflow is flexible in itself, and can support different business processes for different tenants in different ways.
Global bibliometric administration	Even when Pure is serving multiple tenants, bibliometrics can be managed globally. It is possible to globally update citations on all publications, for example, and to update impact factors on journals.
Global system administration	Multi-tenant Pure instances can be administrated globally similarly to regular Pure instances.

Multi-tenancy characteristics in Pure

Development policies

As described under Collaboration and cost-sharing, customers can request custom functionality as a community and share the costs. In addition, Atira often makes standard functionality available, which was originally requested by specific organisations as custom functionality. We have defined two different policies for that purpose:

Policy	Description
Co-financing the extension of existing modules	We have sometimes offered to delivery custom functionality at a reduced price in order to release the functionality in question as standard functionality in Pure rather than as custom functionality. That means, that it has been released to all institutions using Pure and not just to the requiring institution.
Creating a new module	In addition, we have sometimes offered to develop and release a new module containing the desired functionality. In those cases, the requiring institution have been able to just buy the module once released, which is significantly cheaper than financing the entire development.

Policies for co-financing

When custom functionality is delivered as standard functionality instead, one benefit for the requiring institution is that it will be broader than the original requirement - it will cover more usage areas. This is because of our effort to make it usable by all owners of Pure instead of just the one making the original requirement. Another benefit is, that the same (or better) functionality is delivered at a much lower cost to the requiring institution.
The benefit for Atira and the other Pure-owners is, that Pure sees faster growth in relevant standard functionality compared to a traditional, commercial business model.