As mentioned on my personal 'UCS' page, these comments are informal, and the definitive starting point for the Information Strategy at the University of Cambridge is as reported in The Reporter. Also the university has an Information Strategy and Services Syndicate which is an academically-led body overseeing all investment in IT across the university which I am personally keen to have succeed.
A workable information strategy within an enterprise critically depends on the use of effective reference data for a variety of core entity types (e.g. an identifier for a student, member of staff, or an organisational unit) and also the strategic implementation of systems containing what I will call enrichment data (e.g. the course marks of a given student). The essential point is that the reference data should have widespread use across the organisation, while the enrichment data should sit in one place only.
This does not mean there should be one uber-system containing all the information anyone could possibly want to know, in fact quite the opposite. Multiple systems should be 'joined-up' through the use of common reference data, and if it is agreed that the personnel system should be the definitive record of an employee's home address, then that data should be retrieved by other systems as needed from the personnel system using the agreed reference identifier for an employee as the lookup value.
We currently have some systems with their own reference data for important common entities making joined-up access difficult. The worst behaviour that individual system owners can exhibit is to extract enrichment data from an agreed definitive source, modify it and then use it in their system or even worse publish it out to be re-used elsewhere. Similarly, owners of systems containing valuable enrichment data should strive to make that data available elsewhere, rather than limit access to the information to a handful of specialist users via the dedicated application screens. The University of Cambridge Computing Service is committed to making information from within its systems available to federated institutions via secure channels with the appropriate constraints applied to each access. In practice this means we often tag data within systems with some associated institution identifier to facilitate that future access, which can be quite simple when we think of it ahead of time.
As mentioned elsewhere on these pages, the collegiate university is made up of a large number of organisational units that operate with a high degree of autonomy. The trick for the university is to give these departments and colleges the maximum flexibility to excel in their fields of endeavour, while ensuring efficient enterprise-wide services are adopted appropriately.
I fundamentally believe there are many services that should be adopted enterprise-wide to make the whole greater than the sum of the parts. However, I equally believe that these services should have a transparent charging model so that the relationship with receiving insitutions is a healthy one. Charging for IT is commonplace in the finance industry but rare in higher education. Without a charging model there is too much risk that the central service provider (in this case the UCS) inflates costs greater than necessary, and where the central service provider is in effect a monopolistic supplier the focus on the end-user requirements tends to come second to the needs of the UCS in ensuring a given service is secure and robust. I do not wish to do my staff any disservice with these comments, of course we are all equally passionate about ensuring the university succeeds, but it is important to understand the vulnerabilities of a being a central service provider that isn't fully answerable to the constituencies that we serve.
For supporting an enterprise such as collegiate Cambridge, with a wide variety of organisational units, operating largely autonomously, alignment is essential in the IT organisation. I.e. a significant proportion of the IT resource should be directly aligned to a department or college that those staff support. The model that has evolved at Cambridge is to have a very highly devolved model, with Computer Officers reporting in groups of typically one, two, or three directly into the academic departments they support, and the University Computing Service having essentially no aligned groups within it. This structure has a couple of significant benefits:
- The aligned Computer Officers are very close to the departments and colleges that they support, and hence attuned to the needs of that particular department or college.
- The University Computing Service has an obvious mission in ensuring its services are fit-for-purpose in this federated structure, with some aspect of local control or flexibility for the department or college, and more opportunity for local exploitation of the data than might be available otherwise.
Against the positive comment in the paragraph above, such a highly devolved structure does present challenges for the collegiate university. There is limited opportunity in the career paths of individual Computer Officers, which may or may not be a problem for them but it does create a significant issue in the liquidity of the talent pool. An individual department may be well served by a particular Computer Officer but we should recognise that after a period of time we should help that individual move on in both their interest and the interests of the department. It is normal in any IT organisation that at any point in time you do not necessarily have all the right people in all the right jobs, and Cambridge's current structure doesn't provide enough flexibility in that regard. As an example, there are some hugely technically talented Computer Officers providing a local support role in a small department that would be more productive working on the design and delivery of some university-wide service. As Director of the UCS, the simplest observation I could make would be to note that some local services provided within some departments (e.g. the hosting of a web server) were clever at the time of their creation but now are simply a (small) distraction in the life of the local Computer Officer and a centrally-provided web hosting service should be used instead, and the motivation to make these changes is understandably diluted across our devolved organisation. There are a small number of cases where the devolved structure should directly be recognised as a disadvantage to collegiate Cambridge, e.g. the speed with which we were able to deploy a university-wide wireless network. I would not wish to overstate this issue though. Our wireless network now is amongst the best in the country, and in most cases this devolved and aligned talented team responds very effectively to enterprise-wide challenges of which a recent example was the remarkable deployment of 16,000 VoIP devices thoughout every department and college.
My view is that the optimal organisation for IT for the coming period in the university is to create a structure for all IT staff (including for the Colleges) within the UCS. Crucially, that structure should maintain the principle of alignment, i.e. in the main a department or college knows exactly who their IT staff are, where they are, and how to get hold of them. Some of the 'back-end' functions of IT (e.g. server support, networks) would be provided via a more common provision, common tools would be used, e.g. the helpdesk platform, network monitoring, better use of shared machine rooms, and the goal would be to provide the minimum disruption to the front-end institutional support. We would gain greater traction with the use of common infrastructure (such as the desktop build) which are benefits visible to most people that would think about this kind of issue. But I suspect that before long the greatest benefit to collegiate Cambridge will be our greatly enhanced opportunity to have Computer Officers with limited scope today being able use their experience to design and deliver university-wide services that are great for Cambridge.
A bit of strategy in practice - the Lapwing wireless network
This intentionally informal video explains some of the design goals behind the lapwing wireless network. Lapwing uses strategic reference data for institutions, individuals and groups to control its activity, rather than being a typical stand-alone implementation. This means, for example, the list of administrators for Jesus College is held in the identity management system outside of Lapwing, rather than having the wireless network manage its own lists of administrators. As you'll see in the video, access to the Lapwing network is consistently tagged with identifiers for institution and individual in real-time, so that reporting across those dimensions can be provided.
Now that we have continued with this fairly single-minded approach for a few years, the progress can be reported in an updated video here: