Technology developers: local, connected and strategic
Further / Higher Education (F/HE) in the UK is in the fortunate position to have talented and experienced developers working in its organisations, driving both service development and applied research. Because of this, developers in F/HE frequently contribute to a particularly rich source of technical innovation to the sector.
At ALT-C Paul Walk and I ran a session exploring the concept of the Strategic Developer. Paul is the Deputy Director of UKOLN and oversees DevCSI, a JISC-funded initiative to focus on the development of technical talent with in the UK FE/HE/Research sectors. An experienced manager of developers himself, Paul has been looking at the ways in which technology staff are situated in decision-making processes. Back in the spring, his colleague Mahendra Mahey and I ran a discussion session at Dev8eD about the role of developers in e-learning and the ideas UKOLN are exploring clearly had some resonance. This session was a discussion on the issues around in-house technology expertise in a learning and teaching systems context. Our focus was on the hard technical skills end of the technology spectrum: it is about the coders, hackers and integrators, the people who build and develop software solutions.
Paul’s slides below describe the ideas around local developers, connected developers and strategic developers which underpin the DevCSI initiative.
We had a small but very experienced group of participants.
A-Z by surname: Suzanne Hardy (Newcastle), Martin Hawksey (JISC CETIS), Jo Matthews (UCL), Mark Stubbs (MMU), Jim Turner (JMU), Scott Wilson (JISC OSSWatch).
My take-home messages from our discussions are below, and I hope that other participants will add their thoughts.
The cloud, and software-as-a-service model is often conflated in people’s minds with the outsourced model. In truth there are many models of SaaS that have greater and lesser levels of control for the client. This reminded me of one of my favourite talks Dev8eD: Alex Iaconni on different sorts of hosting . Paul’s observation is that the push into the cloud is sometimes mistakenly associated with a reduction in expertise required from the client. Cloud and SaaS just make some aspects of the system remote, not necessarily all, they certainly don’t always negate the need for in-house expertise.
That said, there are some trends where complexity moves up to the “above campus level”. The sorts of shared services that libraries use are changing the division of labour between technical experts within libraries and those working at a vendor/supplier level. Certainly in JISC’s work on repository and curation infrastructures we are seeing potential for abstracting some functionality (and its expert design) up to a network level. I am interested to see whether e-learning will see similar trends: with some specialisms focussed at the shared service level rather than locally.
In open source, we also see that pooling of technical expertise across employer boundaries. Certainly moodle is a really good example of technical skills distributed between institutions, service providers and the developer community in its own right. The recent case study on MMU’s use of ULCC’s hosted moodle solution is a good example of that. The point was also made that OS coders are connected developers out of necessity and that brings the benefits of greater awareness of other software and approaches.
Thinking now about big contracts for outsourced services, we discussed how an institution needs in-house technical expertise to:
- specify technical requirements to vendors
- evaluate proposals
- negotiate technical detail
- oversee technical delivery
- integrate the external service with local integrations
and so on. In short, to act as an “intelligent client”/”intelligent customer” to ensure that institutions are getting value for money from their suppliers. The complexity of university technical infrastructures mean that vendors who overpromise or underperform are hugely costly to universities. When we’re talking about huge contracts like that at London Met the potential for inefficiency is huge and those suppliers must be carefully managed.
I think Paul’s diagram is worthy of reproducing here:
Incidentally I’m not suggesting here a crude “them and us” characterisation of suppliers and customers. I’m arguing that for IT contracts to deliver effective solutions there needs to be a meeting in the middle. I would argue that it is a good test of a vendor that they are happy to get “their guys” talking to “your guys” as soon as possible. Any supplier who is happy to be judged on results will want to get it right and they would rather have frequent access to accurate technical information than to a contract manager with no mandate for decisions. I would love to hear from developers working for suppliers on whether that rings true, but in all my experience, they need to be met half way by the client on getting the technical implementation right.
We also discussed the way in which in-house technical expertise is managed, and on reflection we were describing some common variations, each of which combines to make institutional set-ups quite diverse:
- institution size matters: a small institution may provide more space for a networked and strategic developer
- seniority of developers matters: some will be more involved in procurement decisions described above
- e-learning developers might be central or embedded in departments
- VLEs treated as part of the enterprise suite or as specialist applications supported by e-learning team
- Whether IT/library is converged or not also impacts on where e-learning developers sit in the organisation
- Patterns of home-grown systems/tools becoming integrated or discarded
- In-house open source solutions mean in-house expertise, but externally hosted OSS has more variation
- Mix of core staff and contracted staff (both long and short term)
- Mix of external technical consultants and coders and the ways in which their knowledge is sustained
- Extent of tactical use of internal and external project funding to enhance in-house technical capacity
- Extent to which developers technical skills and approaches are actively nurtured
- Extent to which developers soft skills are developed in areas like pitching, presenting, supporting users, business analysis, cost assessments etc
Even within our small group there was considerable variation. That certainly suggests that in sharing our emerging models of managing distributed and cloudy infrastructures, we need to clearly state our local contexts.
It was a thought-provoking discussion. It emphasised to me the value of JISC’s support for connecting developers, and the need to continue investing in in-house technology expertise.
Amber Thomas, JISC