Shared Infrastructure Services
From DigiRepWiki
Contents |
Shared Infrastructure Services Programme Workshop 26 June: Common issues
Introduction
Projects and RPAG SIS Sub-Group members were asked to discuss a number of issues that are common across the projects and affect the whole of the shared infrastructure service projects (and in some cases are more generic than that too). These came under the following headings:
- Other providers?
- Sustainability?
- How do you get use?
- How do you articulate benefits?
- Policies that govern the SIS - what do you allow in?
- Who holds data?
A small number of other issues also arose, including how to acquire use requirements?
This report briefly discusses each of the issues, then reports the discussions that took place in the meeting and the proposals that were made as to how they might be addressed.
Discussions
Alternative providers
There is a need to undertake a review of the alternative providers, and this needs to consider not only those who are providing similar or competing services, but also those that approach the problem from a different approach (ie substitute products).
Where there are competing products, consideration of their suitability for the community needs to extend beyond simply looking at functionality, and also needs to consider cost, availability across the sector (ie some services are only offered to large or well funded institutions). There is also a preference in JISC for open solutions, and the openness of alternative offerings also needs to be considered.
When undertaking the analysis, services (in development) should not only use the knowledge that is available within the project team, but should also make use of the service users who are often well aware of what the alternatives are. This should include people from outside the direct JISC development community, who may have a different perspective on alternative providers.
It was noted that most projects do not have the requisite skills to undertake this work, and advice, training or support from the JISC would be helpful.
Recommendation 1: JISC should consider how it can support projects in understanding the alternatives to the systems that they are developing. This might include training, advice or the provision of expert advice from specialists.
Recommendation 2: JISC, in conjunction with the projects and their users, should develop a map of the shared infrastructure services and alternative potential suppliers of those services. This should include what the alternatives are, what the overlap is and what the SIS services offer that are not provided by the competition. If possible it should consider known or likely developments of the alternative services.
Sustainability and gaining use
It was noted that there is considerable overlap between these two, as sustainability is often dependent on gaining sufficient use, and perceived lack of a future for the service can affect take up.
JISC services often have a very long gestation from the initial funding to the rolling out of a service. This contrasts strongly with typical web developments that may have short development cycles and be “perpetual beta”. Many JISC funded developments have seen beta releases as problematic and have discouraged take up as the service cannot be guaranteed in the future. There are therefore questions about suitable development cycles for JISC developments and potential services, and whether institutions should be encouraged to implement and make use of services that cannot be guaranteed. The call process, and need for scoping studies before commencing development can also add to the delays, and a more rapid process might be considered.
Recommendation 3: JISC could consider funding a small number of development centres with a critical mass of staff which could be allocated development jobs, as an alternative to putting them out to tender. The advantages of this include the development of a set of skills that JISC can call upon and which would understand issues including the need to gain a user base and sustainability. Potential disadvantages include the reduction in community involvement in development and the possibility of not getting alternative ideas.
It should be noted that this was not suggested as being suitable for all development activity.
It was also pointed out that those who are unwilling to take up JISC developments and services that are still in beta are also those that are most unlikely to use Web 2.0 type services that are in perpetual beta.
There was also seen to be a tension between being user driven, rapid development cycles and the complexity of the interactions between the various systems that are being linked together.
One of the major problems is the reluctance to make use of systems and services that have been developed by others (the not invented here syndrome). This can be true even within the development of the shared infrastructure services where there is often a reluctance to make use of other shared infrastructure services, it is also true within institutions. This has many manifestations – that the service does not match the current needs, that it is not a service, that is not trusted etc. This is a much wider issue than shared infrastructure services, and is also apparent in the failure of reusable learning objects.
Recommendation 4: JISC should investigate the levers to achieve use and the barriers to the use of infrastructure type services that have been developed elsewhere with the specific aim of determining how these barriers can be overcome or reduced, and then incorporating the lessons learnt in JISC procedures.
Many of the shared infrastructure services within the Information Environment were conceived as machine to machine services, as opposed to having a user interface. However, the current development model of web services suggest that it might be appropriate to consider that their main use could be directly by users. It should be recognised that even where machine interfaces are key human interfaces are also important, they can help with take up, understanding and can potentially lead to other uses.
Recommendation 5: JISC should work with the projects to consider how their shared infrastructure service could be used directly with end users, and consider modifying work plans to put some effort into developing user interfaces.
The shared infrastructure services are being developed at many institutions, and not all are being developed in an environment that is used to providing a service. There may also be benefits in rationalisation of provision with fewer service providers, and thus distinguishing between development and service delivery. (e.g. Intute has reduced the number of service providers). For instance, HILT will probably move to EDINA for any service.
Recommendation 6: Consideration should be given to moving the shared infrastructure services into a service delivery environment (eg Edina or Mimas).
However, it was also recognised that there is a need to ensure that development is an on-going aspect once running as a service. There is a difficulty with development funding drying up once the service is live, and this may be exacerbated if services are moved from where they have been developed to a production environment.
The shared infrastructure services lack user groups which can both help to determine the nature of the service and be ambassadors for the service promoting its use.
It was also noted that JISC is not good at making use of its own services. For instance, the JISC web site does not make use of the IESR to provide its collections catalogue.
Recommendation 7: The SIS projects should identify where JISC itself could make use of their services eg. to provide functionality on the JISC website.
Recommendation 8: Wherever possible JISC should make use of its funded services as a way of delivering functionality (eg using the IESR as the basis of the collections catalogue).
A number of possible models for sustaining services were discussed, including:
- Sharing of research and development from JISC community. Development could be undertaken in the community and then perhaps the resultant services could be provided elsewhere (as with the Red Hat model for Linux or the Apache and mySQL where there is an open and a commercial version with support from the commercial suppliers). JA-SIG has a similar approach with uPortal. However, there is a problem that the two versions of the product may diverge.
- Selling the services beyond academia - this could be to other sectors including schools or commercial organisations or to the education sector in other countries.
- Allow advertising - you can maybe make money to open things out more widely. There was concern that adverts should be relevant to the sector though. e.g. the JIGG ( JISC Information Governance Gateway ) is considering eventually including adverts relevant to governance (data protection, FOI, etc).
- The possibility of different models within the sector and beyond it, but there were concerns over how to control this access?
- Maintaining data is onerous – this needs dealt with. This could be addressed by getting the data providers to keep their data up to date. However, they are only likely to do this if there are benefits for them. This could include requiring JISC funded projects to use the services as part of their terms and conditions e.g. digitisation project description should be lodged into the IESR registry.
- Consideration could be given to a charging model for the services (perhaps – JaNet could collect the fees for them with the network charges or a similar model to networking charging could be employed; SIS can be seen as utilities ). One model worth considering is Access Management Federation – although this is not charged for at the moment )
- There may also be benefits in engaging with other potential stakeholders who could contribute some of the costs if there were benefits to them. This could start with JISC associates – eg Research Councils – NHS – e-Science – the e-Content Alliance group.
- There is a possibility that some of the developments are patentable, and could generate licence income. At the very least, an ideas database might also prevent services being sued or developed being stifled by being able to demonstrate prior art.
- There is a need to investigate the various Web 2.0 models, including the perpetual beta with the concomitant need to promote and expose services to use whether they have an SLA or not.
Other ideas that were discussed included:
- Would there be advantages in working with UUK? There would be a need to sell the offer though. Maybe tap into shared services agenda?
- There may be benefits to having user groups for the services? Perhaps have centres of expertise or early adopters to take stuff on and demonstrate its value in use.
- Services need to be packaged so that they are attractive and can be used easily. For instance through easy plug in portlets. Even RSS feeds can be made user friendly with style sheets.
- There may be opportunities to work with vendors.
- There is a need to make high level managers in institutions aware that free ‘stuff’’can be good and academic based ‘stuff’ can be good.
Recommendation 9: JISC should develop a set of viable models for projects that are moving towards services which projects could make use of and adapt in order to make the move from project to viable service simpler. This should feed into the work that JISC is doing on the development lifecycle, development to service and sustainability models.
Articulating the benefits
There was some discussion as to who the benefits should be articulated to, and it was suggested that it needs to be both to intermediaries (who, for instance, might be implementing systems that can make use of the services) and to end users.
Users were seen as belonging to a number of classes: leading-edge users (who are willing to tolerate perpetual beta - possibly even welcome it), evangelists and the majority, and there is a difficulty in moving usage from the first two to third (and largest) group.
Questions were raised as to whether generic (in the subject sense) services were harder to market, and thus whether there is a need for subject based versions of the services, or at least subject based articulation of the benefits.
Policies that govern the SIS - what do you allow in?
There is a lack of clarity as to who and what the Information Environment shared infrastructure services should be working with. This includes:
- The types of content that systems should be addressing - should systems be only working with JISC resources? Resources produced by the academic community? UK resources?
- The audience for them / who is the intended audience - while it is clear that the main audience is the UK academic community questions arise over how far, and much effort should be used to support other communities and how peering might be done with them.
- The quality of the data that they work with - while data that the services generate can be quality assured
Recommendation 10: JISC should define and clearly articulate policies for shared infrastructure services that define the boundaries for collecting data, the types of peering that are appropriate and how quality assurance of data should be addressed. While there will be some variation depending on the nature of the service there is a need for a common core that all the services can work to. This is closely related to the scope of the Information Environment in general.
There was some concern over flexibility with work plans once they have been "signed off" at the start of the project. Many of these projects are exploring new areas and it does not necessarily make sense to stick to the work plan if either the external environment changes or during the development better ways of proceeding are found. It was suggested that JISC could use key performance indicators instead of milestones to monitor projects. This could then be coupled with agile decision making and fluid project planning. It was also suggested that this might be more appropriate if there were development centres rather than projects.
Recommendation 11: JISC should revisit its project management methods to ensure that they are helping to deliver the greatest benefit, and in particular should consider agile project planning. However it is recognised that programme managers should already allow for flexibility and in many cases it is about a good dialogue between the project and the programme manager.
User needs
It is not clear that all projects have the necessary skills to undertake effective user needs gathering, especially if there is a move towards agile development and consequently a cycle of user needs gathering
Recommendation 12: JISC should consider ways in which it can support projects to either acquire the skills needed to for user needs analysis or to support the process in other ways.
Trust
There were seen to be many aspects to developing trust in a service, they include:
- Trust in their persistence and availability
- Development of a critical mass of users, globally.
- Transparency including transparency of changes / development (as for instance with Wikipedia).
- State funding seems to help with the collaboration.
