Neither is Archivematica (that will be a later post).
Neither is DSpace (still later).
We know that none of these systems will solve all of our problems, and we are well aware of the fact that even after the dust settles and we have an end-to-end, digital archiving workflow, integrating Archivematica, ArchivesSpace and DSpace, all of our problems won't be solved. Today's post is the first in a series that will discuss what each of these pieces of software bring to the table, what they don't (or at least not yet), and why that's fine with us.
The Mythical Man-Month
If you haven't heard of it, The Mythical Man-Month is the "Bible of Software Engineering," so-called by its author, Fred Brooks, because "everybody quotes it, some people read it, and few people go by it." Well, I try to be an honest archivist, so I must admit that I am guilty as charged.
|Don't worry, this doesn't link to Amazon.|
I have, however, read "No Silver Bullet: Essence and Accidents of Software Engineering," an essay written in 1986 that was included in the anniversary edition of The Mythical Man-Month. It begins like this:
Of all the monsters that fill the nightmares of our folklore, none terrify more than werewolves, because they transform unexpectedly from the familiar into horrors. For these, one seeks bullets of silver that can magically lay them to rest.
Exciting, right? The "werewolves" and "silver bullets" he goes on to describe have to do with the "essential" difficulties of in software engineering (i.e., complexity, conformity, changeability and invisibility) and order of magnitude breakthroughs--perhaps something like an assembly line vs. minor improvements to that make that assembly line more efficient--that solve these difficulties, respectively. While some of the examples Brooks gives of "hopes for the silver" are a bit dated these days (or are they?), and while I have a hard time relating to it's emphasis on productivity--he was a manager, after all--much of his essay, especially the section on conceptual attacks on the "essential" difficulties, is as applicable today as it ever was.
A Tip of the Hat to Our Friends at ArchivesSpace
Software engineering isn't easy, and the ArchivesSpace folks deserve a tip of the hat for doing it as well and as transparently as they do. ArchivesSpace, like all pieces of software, suffers from all of the same "essential" difficulties that make software engineering the "werewolf" that it is:
That can make it hard to communicate with the developers of any piece of software, including ArchivesSpace. I found this to be experientially true just the other day: I naively assumed that a change that I had in mind of ArchivesSpace would be (or could be) a simple fix, only to learn that it would require re-working the data model for subjects.
|That's enough about werewolves. |
What ArchivesSpace Isn't (or, More Appropriately, Isn't Yet)
That was a rather long-winded way of introducing the real topic at hand: what ArchivesSpace isn't, or isn't yet, at least for us and in no particular order.
A Mechanism for Container Management
Integrated with Aeon
A Total Replacement for BEAL
|The Bentley Electronic Accessioning and Locating System, or BEAL|
Integrated With Other Relevant University of Michigan Databases
Closely related to the point above is the fact that ArchivesSpace in incompatible with other university systems that keep track of donor information. This is so unique to our situation, however, that we don't intend to write users stories or make formal feature requests for this functionality--it wouldn't make sense for us to request or ArchivesSpace to develop functionality that only works for one user. We are still going to have to figure out what to do, so keep an eye out for a future post with details about how we plan to handle this situation.
Robust Enough for Digital Object Management
Connected with Other Search Applications
In a previous position, I learned that right around 60% of traffic to our digital collections came through search engines, which makes a strong case for integration with search engines (and for a way to contextualize individual digital objects or components of finding aids, since this is where end users land). This lack of integration also has implications for more localized discovery through Merlyn, the library's catalog. For now, we'll keep doing what we're doing, creating MARC and importing them into the catalog, with the advantage that ArchivesSpace will export MARC and we won't have to create MARC manually.
A Public Access Portal
Actually, ArchivesSpace does have a public access portal which more and more institutions are using. However, in the medium-term, we plan to continue to use DLXS for public access to finding aids. Longer-term, we are contributing to (and very excited about) the Arclight project out of Stanford. Preliminary objectives for ArcLight include:
- Discovery of physical and digital objects (e.g., finding aids described using EAD, full text search for digital archival materials, presentation and delivery of digital materials)
- Compatibility with Hydra and ArchivesSpace
- Developed, enhanced, and maintained by the Hydra/Blacklight community
And, Finally, Why All of This is OK
Brooks pessimistically asserts that "no technological breakthrough promises to give the soft of magical results," and that all we can expect is "the promise of steady, if unspectacular progress." However, he is more optimistic about what he calls "promising attacks on the conceptual essence." ArchivesSpace delivers in a number of ways predicted by Brooks in his essay:
Buy Versus Build
For the archivist, the most radical solution for constructing software is not to construct it at all. Whether you're "buying" ArchivesSpace by becoming a member, or "buying" it with staff time (i.e., open source software is more like a "free dog" than a "free beer"), in either case you aren't doing it yourself (building another silo from scratch) or going it alone.
Incremental Development (Grow, Not Build, Software)
ArchivesSpace doesn't make the mistake of assuming you can fully specify a product before coding. The relevant portion of "No Silver Bullet" is worth quoting in full:
The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all of the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.
Instead, developers there follow the agile development methodology in order to better satisfy customers, welcome changing requirements and deliver working software frequently.
Great Design and Designers
ArchivesSpace builds on the shoulders of the aforementioned giants. Archivist's Toolkit and Archon served the community for many years. ArchivesSpace is certainly the best of both of those worlds, and the future only looks brighter for both ArchivesSpace as an archival management software package and for the community at large.
|OK, one more. |
Perhaps the best thing that ArchivesSpace isn't, or isn't yet, is a finished product. Perhaps that is the silver bullet.
 "GermanWoodcut1722". Licensed under Public Domain via Wikimedia Commons - http://commons.wikimedia.org/wiki/File:GermanWoodcut1722.jpg#/media/File:GermanWoodcut1722.jpg
 "The Were-Wolf by Clemence Housman" by Unknown - Scan of original. Licensed under Public Domain via Wikimedia Commons - http://commons.wikimedia.org/wiki/File:The_Were-Wolf_by_Clemence_Housman.jpg#/media/File:The_Were-Wolf_by_Clemence_Housman.jpg