Based in the U.K., Oxford Archaeology (OA) employs about 430 people currently working in the U.K., France and China. The independent archaeology and heritage practice has projects on the horizon in India and the United Arab Emirates, and has completed work in Turkey, Iraq and the West Indies. Puttick also sits on the governing council of the Institute for the Management of Information Systems, an organization that seeks to recognize IS management as a profession. SearchCIO-Midmarket.com asked Puttick to describe OA's IT strategy.
What is the nature of your business?
Puttick: Across most of Europe, planning regulations require various factors to be mitigated before [building] consent is granted. One of those factors is archaeology. In the U.K. and France, any major construction work (and a lot of minor works, too) require archaeological investigations before construction can commence. [Our] projects can be as small as watching builders while they dig out foundations before building an extension to a house, to as large as Heathrow Terminal 5, which had archaeologists on the ground for eight years -- or the Channel Tunnel Rail Link project, which had our archaeologists working on over 67 miles of a planned new rail track.
As a result of the planning regulations, there are a number of archaeological organizations of various sizes across the U.K. and Europe -- some part of local government, a few attached to universities, and a lot, mostly smaller ones, private enterprises. The majority of archaeologists in the U.K. are employed by organizations that are, like OA, charities committed to educating the public about archaeology. Our revenues are drawn entirely from being paid by construction companies to mitigate the archaeological planning requirement.
What are your main challenges in IT strategic planning?
Puttick: The challenges that I would see as being particularly an issue in the archaeological sector, or for OA, are:
Data retention requirements (as in, forever): Archaeological data is extracted in a one-off "experiment" with our teams on-site, excavating before the new road/airport/tunnel is built over or through it. What is observed, measured and photographed can never be repeated, leaving the resulting data the only surviving record of an archaeological site that had survived thousands of years before the excavation, or like this site, a mere 1,000 years, so our records should aim to be retained for at least as long, or the money and effort spent on the excavation was wasted.
Organizing information: Archaeologists like to have their own ways of describing and recording, making comparative analysis systems more challenging than in most situations. This also creates challenges in the development of recording systems, one of the many reasons we focus on the Web, open source and configurable mobile applications for these purposes.
Specialist staff demographic: Greater than 95% of the staff are not only archaeologists, or from related disciplines, but also graduates, with as high as 50% postgraduate and over 5% PhDs. Few have ever worked in wider sectors, and almost none in private enterprise. Of those who have worked outside commercial archaeology, most have worked in the public sector or for universities. As a result, the level of IT skills and awareness is pretty low, and we don't have the training budgets necessary to make up for that, so we have had to get creative with the use of IT champions in other teams: forums, wikis, the whole enterprise 2.0 thing I guess, but not in a traditional way.
What is your data center strategy?
Puttick: Data center seems a very grand term for what we are doing to develop long-term storage. We're being very pragmatic (we are a nonprofit, so every penny counts) in our approach, but trying to be holistic, too. Archaeological data is stored not for some legal purposes where you need to tick the box that says, "Have you got your data for the last X years?" -- a requirement that tends to result in the archiving of the data on to tape or optical media -- but for access. So the data has to be kept live, or as live as practical. The flip side of the need to keep it live is that the data is not in continuous high demand, so there is no need to think Fibre Channel and 20k RPM hard drives and 100 Mbit Internet connections; it's more about maximizing value, or more specifically, the lowest possible cost per gigabyte.
What is observed, measured and photographed can never be repeated, leaving the resulting data the only surviving record of an archaeological site that had survived thousands of years.
CIOOxford Archaeology Ltd.
There are two basic types of data to store: the high-level reports, which we are starting to provide via http://library.thehumanjourney.net; and the images, for which we have yet to find a satisfactory method of storing and providing. One large project can provide tens of thousands of images, and we do hundreds of projects a year, albeit not many of them are large. Right now, images are stored in a Samba-fronted Sun J4200 disk array; and, finally, there are the raw data, observations, spatial measurements and carbon dates, etc., which are stored in various ways.
What new technologies are helping you meet your goals?
Puttick: The plan being implemented to deal with raw data has two strands. The first is the adoption of the (open source) document management system KnowledgeTree (KT), on top of which we are building an application-level replication system. In this, the user stores the document, which goes into a queue, from which it gets replicated to separate instances of KT on other sites. A database management system will store all the files generated during a project, along with scans of paper records, including observations taken on-site. The second strand is the development of a spatial data infrastructure (SDI) for all the spatial data. We intend to move to on-site electronic data capture, whose output will end up in the SDI, utilizing Android mobile devices (Motorola Milestones).
On the services side, we've virtualized using KVM on Ubuntu. There is a possibility that some of these services will eventually migrate to or be replicated in the cloud, as they are small enough to make the move fairly painlessly.
Could you describe your disaster recovery plan?
Puttick: Our solution is cheap disk in large quantities, replicated to multiple sites; right now we still use tape for DR, but it cannot scale sufficiently and is too slow for good business continuity. The plan is proceeding.
Let us know what you think about the story; email Laura Smith, Features Writer.