Mike Banahan, February 2006
This case study investigates two related aspects of the use of the APLAWS (Accessible Personalisable Local Authority WebSite) software across the UK and in Cambridge City Council in particular. The user-specific aspect of the study considers the use of APLAWS in Cambridge City Council, a more general aspect is the nature and management of the APLAWS project itself. The software has been developed and disseminated in ways that differ from many Open Source Projects and is considered to be both successful and potentially a model for similar developments.
Because local authorities do not compete with each other in any serious commercial manner, they have the potential to collaborate on the production of software to meet their needs and the Open Source approach is one that shows promise for mutual support and cooperation. APLAWS represents a valuable pilot example of that collaborative approach.
Local Authorities have a duty to communicate with their users. At the turn of the milennium this was underlined and given particular direction by E-government initiatives to provide comprehensive access to information and services through electronic means, in particular through the use of the Internet and web-based access.
Small-scale websites can be built and maintained by a team of experts but that is not a suitable model for local authorities. The only reasonable model for the construction and management of large-scale websites that meed their needs is through the use of content management systems (CMS). At the time of the move to large local authority websites commercial CMSs were also coming into existence albeit typically incurring not only high adoption costs but also high costs of tailoring to render them suitable for the needs of each authority.
The APLAWS project was started as an Office of the Deputy Prime Minister (ODPM) Pathfinder project, being developed collaboratively by a number of authorities and commercial partners. The software was built as Open Source so that it could be adopted and deployed by other interested parties without incurring licensing and other costs.
Cambridge City Council has deployed APLAWS on a predominantly outsourced model (implementation and continuing support) and now delivers its web site and content development through APLAWS. The deployment took around a year in total and now runs satisfactorily causing few worries.
In general APLAWS shows that local government could benefit from a better understanding of, and clear guidlines for, appropriate mechanisms to ensure longevity and good governance of collaborative software projects. It would be useful to develop a detailed analysis of potential cost savings from this route.
APLAWS was intially developed by a project team drawing on a range of disciplines (modelled on the PRINCE project management framework):
Funding for the initial APLAWS project was cash and time limited. The project was considered to have been successful at the end of its pathfinder phase, resulting it its being taken forward into the National Projects Programme as the Content Management component of the Local Authority Websites National Project, at detailed description of which is available atwww.aplaws.org.uk/project/laws.php. The overall aim was to deliver a freely available content management solution that met the interoperability, metadata and accessibility requirements set for UK local authorities. The LAWS project describes one of its aim as "to develop a suite of low-cost, local authority-focussed applications and standards to help councils provide a wider range of higher quality services on their websites".
The software is freely available for download from the sourceforge.net/projects/aplaws Sourceforge repository.
Principal responsibility for the selection of APLAWS and continuity of the delivery of the service lies within the Council's IT department. IT support in Cambridge City Council is outsourced and there is no in-house involvement in support activities. Support for the APLAWS service is contracted through Runtime Collective, a software house that specialises in APLAWS support. Other sources of support are also known to be available.
The council's various departments are responsible for content on the website, using the workflow and editing processes that are supported as part of the APLAWS content management services.
A small working party was set up when the need for a CMS became obvious, the working party established requirements for workflow, meta-data and other project goals. That working party remains available to oversee requirements within the council.
Large-scale Content Management Systems tend to be expensive and highly generic. As software becomes more and more generic to meet the needs of a wide market it tends also to require more and more tailoring to the needs of specific users. This can been seen in large software packages outside the realm of CMSs such as Customer Relationship Management or Enterprise Resource Planning - typically expensive to buy and then requiring prodigious efforts from a team of onsite consultants to make it work for the enterprise deploying it.
At the time that local authorities were being pressured to respond to the e-government strategy, enterprise grade CMSs were relatively young and already exhibiting the features of those large generic packages described above. Whilst commercial organisations usually find that competitive imperatives make it hard to cooperate with others to build line-of-business software, local authorities are not similarly constrained. Furthermore, their particular needs for compliance with e-gif and other technical constraints tended to put their requirements outside the 'comfort zone' of the available CMS frameworks available at the time.
Rather than each of them spending relatively large sums of money on proprietary CMSs they chose to cooperate on building an application that would meet their needs, based on an Open Source starting point contributed by Red Hat.
Red Hat developed the underlying system from software acquired from Ars Digita, a company that folded in 2001 (source: news reports and personal 'blogs' via Google) whilst in the process of building an Open Source CMS. Red Hat's software remained Open Source under the name of CCM (Content and Collaboration Management). This is the kind of thing cited by Open Source proponents as a good reason for picking Open Source software, claiming that it reduces dependence on the success or failure of a single proprietary company.
Before their commercial collapse, Ars Digita reportedly (ZDnet) were originally funded to the tune of several hundred thousand pounds by Camden, giving some indication of the sums of money involved in producing tailored CMS systems for UK local government.
A hand-made website has grown up at Cambridge prior to the use of a Content Management System. As usual, there was a lack of consistency in style, content, publishing process, use of metadata and attention to navigation and accessibility. This situation was typical of most local authorities at the time of the development of APLAWS.
An external consultant advised Cambridge City Council. Amongst options available were
A small internal committee was formed to evaluate the options, working with the consultant. The eventual decision was to use APLAWS. Amongst the reasons for choosing APLAWS were its overall approach to providing local authority websites, the active community of users and a willingness to adopt Open Source approaches which was encouraged by some of the technically literate elected members of the Council (Cambridge is of course a hi-technology hotbed). Lowest-cost was an important but not overriding factor in decision-making.
The APLAWS+ (APLAWS+ is the later version of what's generically called APLAWS) system is based on a three-tier architecture.
The back-end of the system is a database which stores the data used by the websites - published data, metadata, user rights, work in progress and other relevant information. The back-end was originally limited to Oracle, but this is not an Open Source product and is considered by some to be expensive overkill compared to the later addition of PostgreSQL. PostgreSQL is a well-established Open Source database which can be used free of charge. Versions of PostgreSQL exist for Linux and other Unix-like operating systems as well as for Microsoft Windows.
The middle tier of the system is the Application Server Layer. This takes the data from the database layer and formats it for presentation. The software in this layer is predominantly Java servlet technology and can be run using Apache/Tomcat or Caucho Resin, both of which are Open Source products published under the GPL licence.
The front-end to the system is the web server which provides a cacheing service to the middle tier and also serves static content. This is typically implemented using Apache (Open Source, GPL) or a combination of Apache and Squid (ditto).
The hardware and software requirements to run APLAWS are relatively modest. Clustering may be used at the webserver and application server layers for improved availabitlity or where high loads are expected. Instances of APLAWS have been implemented on various versions of Linux including Debian and Red Hat and in principle there is no reason why other Unix-like or even Microsoft Windows operating systems should be ruled out.
The data flow through the APLAWS system is important to note. The Application Server Layer is designed to produce XML documents which are then transformed through XSLT and CSS: whilst this can be subverted it is recommended not to do so for reasons of good practice and maintainability.
The APLAWS+ Best Practice guide makes recommendations based on experience of the deployment of the product in a number of local authorities.
The adherence to standards is quoted as an important plus point for APLAWS:
"A major part of the project has been implementing standards, [...] technical standards such as XML and standards for local authority sites. On the technical side, APLAWS makes heavy use of XML, with XSL for styling, and is programmed in Java. The use of government standards, in defining navigation, categories of services offered and metadata for instance, has become one of APLAWS' biggest selling points, [...]. An example is a suite of lists, controlled by a central standards body and built into APLAWS, that defines every service offered by UK local authorities. "Apart from the quality of the system, and the fact it is open source, a big reason for people to choose APLAWS is that out of the box it complies with all the standards." (Arturo Dell, Camden, quoted in ZDnet)
Cambridge City Council's implementation of APLAWS is run on Linux, PostgreSQL and Apache. It is one of the most heavily used local authority websites in terms of visits per head of population, probably because a higher proportion of its traffic comes from visitors and tourism than similar sites elsewhere. Software support is provided by Runtime Collective and hardware support by Serco.
Deployment of APLAWS at Cambridge City Council was a significant project, taking a year to implement. Project Management was arranged by Runtime Collective, assisted by an in-house team during the implementation phase.
Technical aspects of the deployment were not particularly difficult, although it is felt that this might not have been the case if Runtime Collective had not been available to provide product-specific expertise.
Overall presentation and navigational design for the website was done first, followed by a long process of converting existing material to fit the new structure. The bulk of that work was outsourced, validated by the departmental owners of the information within the council. This is the area where the greater part of the cash cost of conversion was necessary.
An initial group of 30-40 council employees trained in the use of the system has, after a year, expanded to some 100 or so in total.
The project was managed on a fixed-price contract basis with the outsourcers.
The APLAWS comparison guide quotes a price for implementing a basic APLAWS system as being in the £15,000 to £30,000 range. This is by any standards a very modest figure, which in any case will pale beside the organisational costs of populating the CMS with the level and range of information required by a local authority.
Cambridge City Council felt that a comparitive cost analysis would have had marginal benefit in evaluating APLAWS. The software and system costs are relatively small compared to the migration costs incurred in producing a properly structured website and converting existing materials to fit that structure.
At Cambridge, the APLAWS system does what was asked of it. Departmental authors and publishers receive half a day of training before making use of the system. The user interface is perhaps less slick than some other CMSs offer but it does not pose problems and users are able to perform the tasks that they need to do.
At Cambridge administration is outsourced. There is a suspicion that APLAWS requires detailed technical knowledge to keep it running but in practice it works.
Cambridge found that setup and initial configuration took more time than had first been expected. Once that had been established, the deployment process was relatively smooth.
The APLAWS deployment at Cambridge has provided a stable and reliable platform for the production and delivery of web content. There are no serious worries about it.
In the year since it has gone live there have been two minor service outages and no security issues observed.
The technical lead on APLAWS development is at present undertaken mostly by Camden Borough Council, Red Hat and Runtime Collective. It would appear that this is working well.
There seems to be a less clear picture on managing the end-user requirements process and there may be lessons to be learned here about how to conduct collaborative work in local authorities. APLAWS is a pioneering project in UK terms and most of the rules have had to be made up as the project has progressed.
There are legal issues arising from this kind of collaborative work and, given the requirement for public probity and accountability, it is not as easy as it might be for commercial or community developers to become involved in speculative or risky projects. As an example, if several authorities conclude that a new feature needs to be developed for APLAWS and jointly choose to fund it, what happens if one is unhappy with the results and declines to pay - are the others obliged to pay in any case?
APLAWS, followed by APLAWS+, has demonstrated that an Open Source project can survive the failure of its originator and maintain a life of its own in the public sector. Open Source enthusiasts will argue that this alone is a strong reason in favour of this style of licensing, this case underlining their view with a high-profile public sector example.
Cambridge City Council have demonstrated that the software can be deployed with modest effort, giving a stable base for service and content delivery.
Some 40 local authorities in total are reportedly working with APLAWS giving it a substantial user base.
The APLAWS website links to a comparison guide which makes a strong argument for the suitability of APLAWS when compared with commercial alternatives in most cases.
The APLAWS project is in the process of being constituted as a separate entity with ownership of rights being transferred from the Office of the Deputy Prime Minister to Camden.
It would seem that the initial work funded by central government demonstrated that local authorities can work together on an Open Source software project with considerable success. Although a significant sum of money was spent with ArsDigita prior to its folding the work was able to continue in a collaborative way, aided by the fact that the parties in involved had a common goal and were not competitive with each other. Unfortunately when funding for the project ran out there was no established framework through which this kind of project can be carried forward and anecdotal evidence is that it stalled at that point. Currently, efforts are under way to transfer the rights involved to a body that will continue to support and develop the project but there is no obvious template for work of this nature to fit into and it is being done through best-efforts and good offices of the people concerned.
As an external observer there are some important points that I, the author, feel should be made.
In the opinion of the author a full case study on the background to and subsequent evolvement of the project would be valuable as a model for Government. At present it appears that the bulk of government procurement is based around the purchase or commissioning of proprietary software, as distinct to initiatives such as APLAWS or the US Department of Veterans Affairs VISTA health care software suite. UK Government could well benefit from taking a more community-based approach to software development for the public sector.
Whilst APLAWS and VISTA suggest that collaborative development may have cost and other benefits they represent only two quite different types of public sector Open Source projects. It is misleading to generalise from pioneering work which, whilst it can be an indicator of issues that need to be resolved, does not necessarily provide templates to follow. The argument that the public sector can and should undertake more collaborative and shared projects cannot be resolved by reference only to these two cases. Cost savings and better fitness-for-purpose may be achievable in this way but a robust approach that is well-understood will only occur if more of this kind of work is done, studied and documented. Without a clear central lead and will that may not occur, or if it does, it will be by accident rather than design.
No appendices are included in this case study.
These references are not necessarily supporting the contents of the study, some are included for further reading.
All trademarks are acknowledged as the property of their respective owners.