MEAOT Project - managing local innovation
The MEAOT project at the University of Cambridge took two existing administration tools developed in-house by specific departments and sought to extend their use to other departments.
The key areas of innovation were the two tools themselves, (1) the Teaching Office Database (TODB), (2) the Student Choices, but also the models of development, customization and deployment that were undertaken. In particular the "trunkless" customized development model used for TODB is identified as a significant innovation (3). For this review I'll look both at the tools, but in terms of innovation the methodology for supporting local development is perhaps the most significant aspect of the project to look at.
TODB stands for "Teaching Office Database" and is a system for managing the allocation and tracking of staff time on common teaching tasks such as supervision, lectures and seminars. Administrators add teaching tasks to the system, which can then calculate approximate workloads. The best way to understand what TODB does is to go and try out the online demo.
TODB is a fairly basic web application in the general vein of time tracking and scheduling applications - this is something that people tend to have to do in a wide range of jobs and industries, so there is a lot of generic software in this category. The key issue with such systems is customising the information collected to fit the types of work and the way it is tracked (e.g. by cost centres or project codes) and to integrate it with other systems that provide data such as rates, codes and so on. However, TODB is not really intended to be a sophisticated and feature rich time/task management system, but rather as a simple database with some web forms that an administrator can customise themselves.
It is also worth looking at the Learning Design Support Environment (formerly the LKL Pedagogic Planner) which is another system for planning teaching activities, from a slightly different viewpoint where the emphasis is on the types of teaching methods being used rather than resource tracking. However the actual tools are quite similar in some basic respects, and it would be interesting to see just how much overlap there might be.
While TODB is certainly not that innovative as a system, it appears to have been successfully adopted at Cambridge, with eight departments evaluating the software, five of which seem committed to using it in production.
One of the reasons that is given for this success in adoption is an approach that encourages departments to freely modify the tool; this is something discussed later in this review under the heading of "trunkless development".
Student Choices emerged from a set of diverse requirements that originated from an in-house student and course management system within the Physics department. However the project quickly determined that there was relatively little scope for use of the tool beyond the original department - partly as it provided functions that were adequately met by existing central systems. It was an interesting consequence of the project that the central student data management team has begun work with the Physics department to ensure they have a solution that also fits the wider requirements of the University for central reporting of student numbers (for example). Though as the report says "However, this action has also rendered our developed software redundant." I think actually this was a very good result!
Trunkless Development approach
One of the main innovations of the MEAOT project is an approach to supporting local innovation " described by the project team in their report is something that she describes as a "trunkless development approach".
Basically what this means is that each department that wanted to use TODB took a copy of the code and then were free to customise and extend it however they wished. This is not quite the same as a typical OSS "trunk and branches" model in that here the core initial code is a prototype with very limited functionality and little attempt made at abstraction. The idea is that each copy of the application is kept very close to the needs and to the understanding of the small group of user-developers so that they can easily rewrite the application if they wish to.
Looked at as a general process, it doesn't really look all that different from any other software process:
- Prototype developed by originating user
- Other users interested
- Central, one-off funding obtained for development
- Software is genericised, with a view to making expected range of stakeholder-specific customisations manageable
- Software deployed and customised user by user. Users and developers agree priorities for development.
- Lessons are incorporated back in to generic version and pushed to previously-addressed departments
- Detailed, tested documentation and handover to users
(from MEAOT final report, 2010)
One could take the above description and apply it to anything from Apache to Moodle. However, I think the difference in ethos could be characterised as "folk coding" - rather than the OSS processes that tend to be quite rigorous and applied by professional software developers, this approach was intended for use by departmental staff who dabbled in a bit of PHP and had no experience of or interest in such staples of software development as source control. I think also given the stated dislike of using standardised libraries as dependencies that the term "folk coding" makes a lot more sense than "trunkless development" as it seems to be a rejection of the techniques of modern software development to embrace a more DIY, almost anti-engineering approach to creating applications that are closer to the day to day concerns and problems of user-developers.
Off to do a spot of PHP development at Cambridge
In that sense its somewhat counterintuitive. My first take on reading "trunkless development" was to think of Github, which is a social coding environment using the Git source control system. In Github, developers create "clones" of interesting code, improve on it, and then allow their derivatives to be merged into its parent project if so desired. Indeed a very similar activity took place within MEAOT, but using a completely manual process:
"Maintaining eight independent branches means each time a change is made to one that might be useful to all, a rather laborious merging process is required to ensure that the new functionality is available in other departments but does not overwrite some other department-specific changes."
Overall the model of "folk coding" to create department-maintained code is interesting, but as the report freely admits brings its own issues. For example, it seems to use more resources than a professional OSS-style software development model, however it distributes the usage of resources across independent departments, who have to then maintain their own variants. In some ways it resembles a software version of the widespread practice of departments keeping their own versions of enterprise data in the form of personal spreadsheets and Access databases - something which is very much frowned on in the wider world (I once worked for a company that provided data services to banks, where this type of practice still occurred, despite being absolutely forbidden on security and privacy grounds). Interestingly, the Student Choices work in this project provided a good counter-example, whereby a local student record system was identified as being potentially problematic, and central student data management have become involved to propose a centrally-supported solution.
The question JISC have asked me to answer in these reviews is basically "how innovative is it?" In this case I'm not quite sure how to answer. In many ways "trunkless development"/"folk coding" could be seen as reviving a set of outdated development practices (if you replace "PHP" with "Visual Basic" you could be looking at a description of common practice circa 1990). However there is innovation here, and that innovation I think is in two parts.
First, there is identifying a potential business case for these applying these kind of "anti-patterns" in areas that are left relatively untouched by enterprise IT investments - business processes that are limited to only a few members of staff, or are a sort of "barely repeatable process" (a term coined by Sigurd Rinde) that is unlikely to be standardised as a formal business process but can benefit from some form of automation, as long as it doesn't take too long or cost too much. (Perhaps MEAOT would have been as well advised to have looked into solutions such as Thingamy as an alternative to relying on departments having people with PHP skills?) However, as the Student Choices experience also shows, in some cases there also need to be interventions to replace local applications with central systems.
There is a lot of "folk coding" already going on in institutions - for example in my own university I've seen quite a few bespoke departmental admin and workflow tools in a range of programming languages; I've even written a few myself (this blog software included). The second innovation introduced by this project was to try to embrace and improve this practice rather than to either ignore it or discourage it. I asked several colleagues in IT services and they had difficulty locating any policies or common practice in this area other than a few vague statements from some institutions discouraging the practice of local application development.
Currently, while there are best practice frameworks that consider application management and application service portfolios (e.g. ASL and ITIL) there is little that is specific to managing local innovation and local application development. I asked Sandra Whittelston, chair of the UK Education Special Interest Group in ITSMF (IT Service Management Forum) about this topic, and she commented that:
"In V3 ITIL we consider operational, tactical and strategic development (of course) and I think this may be useful in approaching this topic (from an apps developement sense) in that trying to control software developed locally (for local reasons) is a challenge. From a business perspective understanding why people do it and the risk of letting it get out of control whilst still allowing flexible handling of information is key."
"From the strategic vantage point service portfolio management is crucial as it allows us to see a birds eye view of our whole portfolio and its status. This of course should include locally held systems and services. Live apps should be included in the live part of the portfolio.."
The role of a central IT project in MEAOT for the TODB solutionwas to introduce a kind of "limited professionalism" in terms of keeping common source code under control but not committing to maintaining the in-use code, and to support the requirement process. This in itself is an interesting innovation, and it also makes sense given the ethos at Cambridge of local autonomy.
The team write in their report:
"Criticism of the software development methodology used with the TODB has been leveled at the difficulty in supporting software that, at the time of release, has eight slightly different versions, and may have been independently modified further without knowledge of changes being fed back to the support team. The simple answer is - there is no support burden! The whole point of the trunkless, decentralised model is that departments are self-supporting. This is a 'launch and forget' model. Were such a model used more widely, it would be wonderful for software developers, who traditionally enjoy developing new things and despise the 'housework' of ongoing support. The temptation to compromise the constant focus on local maintainability must be held in check, however."
I think this last sentence is important - if a central IT service team introduce "limited professionalism" into department-based "folk coding" projects, it has to be with clear expectations on all sides. I think this would be one of the challenges to follow up with the team at Cambridge a year on to see if departments have continued to maintain their own variants without drawing in the project team members who presumably will have wanted to move onto other activities.
If I were to make one suggestion to throw into the mix it would be to make a concerted effort as part of the initial intervention to get those involved familiar with Github and its model of social coding, as while it doesn't impose a more structured way of working, it does make the process of merging much less problematic, reducing the effort required to coordinate the different variants. However, there will obviously be a temptation to try to turn "folk coders" into software engineers, which isn't the point at all.
However, when we look across the two systems that MEAOT worked with the approach to application management could be characterised as pragmatic problem-solving rather than a top-down "enterprise architecture"-style approach - either supporting local innovation, or enabling centralisation whichever is appropriate to the situation. I think that given Sandra's comments it might be useful to see if there are lessons learned here that could contribute to the wider understanding of local application management, for example through UCISA's ITIL group and ITSMF.
Photo by Darren W