Applied Architecture

Jim Blackaby, Mystic Seaport Museum, USA http://www.mysticseaport.org

Abstract

The Mystic Seaport website has been developed with an increasingly carefully designed underlying architecture that ties the website to the museum's electronic information resources. While this is common in the presentation of collections materials, the extent (and success) with which this has been realized in the areas of public programs, products, education, and membership is not. The integration of these elements has meant an increasingly sophisticated way of managing our museum information generally with the web as the occasion for that management rather than the result.

Keywords: Information architecture, museums, inforamtion management

Applied Architecture

While technology brings benefits, it also creates problems. Those problems may not increase in some geometric proportion to the complexity of the technology, but it is certainly true that one can end up in a substantially grander fiasco by choosing bad accounting software than by choosing nine column instead of eleven column accounting paper. At Mystic Seaport, we are trying to reduce the effects of those problems by understanding what our information architecture is and acting on that understanding. We are using the web to realize that information architecture because the web offers a set of tools for combining textual, database, and visual materials with sophisticated presentation capabilities along with the capacity to import and export content where that is needed. The remarks that follow are based on some preliminary experiments. A broad outline will be presented, one simple example that we have been developing explored, and finally a suggestion of some benefits that have accrued from this approach will be offered.

An Overview

In the 1980's the 'watch out' for technology planners was proprietary systems that bound data and their programs inextricably like Siamese twins so that when the program died or wanted changing, the data was apt to die as well or was rescued only with great pain. In the 1990's the 'watch out' was making sure that the programs implemented did not end up dictating the structure of your organization or work. Membership and Development may be closely related in museums and quite separate from Finance, for example, but is this because most membership or development software packages commercially available combine those two functions and most financial software systems don't include them, or because that is truly the shape of our work? In the new century, we are obliged to contend with the missteps of the first twenty years of computerization in museums, but beyond that, technology planning involves understanding our information architecture, our audiences, and our business. At Mystic Seaport, we have developed a relatively simple model for our information, and we have used the web as an occasion for testing and enhancing it. When we reach the next decade of this century, we are sure to discover that we did not avoid all of the technological potholes that we'll encounter. Future technologies will have to contend with our missteps. But, understanding our architecture helps us to choose wisely, and may help smooth the transition into changing technologies by preserving our data in ways that support our ongoing work.

Our approach has been quite simply to borrow from the many years of studying, storing, recalling, and utilizing collections information in museums. While the process of understanding and re-thinking museum collections information that has unfolded over the last twenty years has been far from linear or even intentional, museums have benefited from being able to grow their ideas in step with changing technology. The simple field-tag and data technologies of the 1960's and 1970's were rethought first as simple grids and then relational models as database tools evolved in the 1980's and early 1990's, and those ideas have matured with object models and the kinds of faceted views that tools like XML bring to the mix along with the notions of digesting complex structures into a few core fields that give access to deeper information. Museums are often criticized for their apparent lack of standards, but that very lack has enabled them to bring openness to the technologies that have emerged for managing information. That museums have been thinking and re-thinking their data over the last twenty years means that they have developed a reasonably sound set of tested skills in thinking about information.

What museums have learned is that fairly simple relational models can describe complex concepts, and that in spite of the possibility of extraordinary complexity for any of the entities within those models, a simple set of shared elements can be defined. Beyond that, museums are comfortable—whether they really know it or not—with information models like object-oriented data structures or with the kinds of partial views that tools like XML and SGML can provide. A catalogue record—even a very rich one—cannot, indeed need not or even should not, do more than act as a gesture towards a real object whether it is a painting or a molding plane or a bird skin. One can quibble with the details, wisdom, some of the paths, and some of the outcomes of this mode of thought, but the fact remains that this is something we in museums have learned to do. This is not a small accomplishment or a simple habit of mind to develop. Of course, information scientists and technology designers knew all of this more thoroughly and more theoretically long before it filtered down to museums, but for casual travelers along the information highway, museums have done well.

The Basic Elements

Building on our understandings of collections information, then, one can suggest that all of the information that museums manage can be characterized in a fairly small set of elements that have relatively simple sets of core characteristics, even though any of these elements may point out to things that are much more complicated than we care to describe but from which we can extract enough of a view to be useful.

At Mystic Seaport we have identified seven such basic elements about which the museum has information:

Each of these has a few basic characteristics: Calendar information has date, time, and duration; People have names and personal information; Products have identifying features, costs, and data about availability. None of these is truly very simple: Publications take all forms from books to exhibit labels to interpreter's handbooks to mission statements to websites; Programs might include formal lectures, on-site demonstrations, special exhibits, focused classes, or ongoing activities like volunteer opportunities. We know lots about the complexity of Collections: objects, manuscripts, books, films, photos, audio recordings, 'educational' collections, reproductions, etc., etc. We also know that there are all kinds of proprietary, formal, informal, accidental, electronic, manual, open, closed, and tight-lipped systems that truly lie back behind each of these seven basic building blocks, but we've learned that doesn't matter. Museums know the trick of working with the tips of icebergs.

One could get elaborate with this approach—more basic elements, more characteristics—but the end result is not so much to manage these kinds of data (though that does end up happening to a degree) but rather to use them. The important thing about identifying the basic building blocks is being able to combine them into basic functions. For instance, the Programs combined with the Calendar becomes the course offerings for any period of time. That combined with the People element is what is needed to register people for the courses (and, of course, Resources gets input when they register). Similarly, the conjunction of the People element with the Products element (again with the ultimate involvement of Resources) characterizes any sale transaction.

An Example: Products

One of Mystic Seaport's businesses is selling things. Some aspects of this are relatively clear: we have a museum store. Some are not: we provide research services for a fee and we license the use of our collections. Some, like memberships, don't depend on any 'inventory' per se. Others, such as donated boats for sale, are inventoried, but not in the same sense as the t-shirts in the museum store. The sale of copies of ship's plans for boat builders or of photo reproductions of turn of the last century passenger ships for those whose genealogical research leads them to those vessels are businesses on demand. The sale of special member's hats to members involves screening the purchasers as well as maintaining an inventory that may have a long life. The products that we offer are varied.

We do have some systems in place for managing the sales of products: for most of the things sold through the museum store, there is a commercial software package that maintains all kinds of cost, inventory, supplier, date received, wholesale shipping, tax, location, descriptions, manufacturer's identifiers, inventory numbers, sku's, ISBN numbers, and on and on. In its way, it is as complex and as functional as our collections management system. For other product sales, our systems are less formal. The collections management system has a module for tracking rights and reproduction information. The membership program has the capability of managing a few products for sale to members apart from the memberships themselves. And, there are some home-grown databases for storing information about which ship's plans are available for sale and which photographs might be reproduced. But, there is not a universal system that manages products, and we know enough about systems and software and the effect that those have on our work that even if we could squeeze everything into our store system (and we probably could), that would not be desirable. Just because it is our biggest, most expensive system does not mean it is the best for all products, and just because we might be able to force integration of all of our parts does not mean that would be prudent.

Instead, using the web as our perspective—a view of the whole organization and its functions rather than the departmentalized view imposed in part by our business software, our practices, and the nature of our products—we looked for commonalities among our products. They share a few:

Starting with these simple elements, we began to construct a product database that had the following:

Along with this database, we've developed programs that either extract from our product managing systems information or provide product managers with ways to represent their materials. Some of these extractions occur regularly ̉the museum store inventory (roughly 30,000 items) is polled every night to update quantities available and price as well as additions and subtractions. The list of available ship's plans does not change more often than quarterly. The membership categories available as products change less frequently than that. We are still at the beginning of this process, but by adding product lines and capabilities slowly, we've been able to keep our product database simple. The goal, after all, is to create something that can intersect all of the products that we offer and to get the same set of basic data about them so that we can use that information. It is not to either reproduce the management systems that any products may originate from or to create a management system where none exists.

The logic of the Products database is to simply intersect with all of the native sources for product information. Very little of the native information is required to create this central element.

Some Benefits

The most obvious benefit of having a single product database drawn from our existing systems is that we only have to build one tool to create a transaction. From the point of view of maintenance, this alone is a tremendous benefit. But, more interestingly, perhaps, is the fact that this model does not depend on any particular software solution or set of procedures or even data structures (though having everything in a common database language helps ease the extraction routines). If the store, for instance, changes to a new software solution, the only change needed in the museum's information systems as a whole will be a new extraction routine to populate the Products database. Because the structure of that Products database is basic and simple, creating a new set of crosswalks should be straight forward. If the membership department decides that it wants to let the store sell its merchandise or the sailing programs add a line of sailing accessories for sale accommodating that in the Products database is simple.

Transactions are created between the building blocks—Products, People, and Resources in the instance of a sale—not between any of the underlying native data sources.]

Using the databases singly to store information harvested from our production systems is hardly the goal of this approach to information, though. The important benefit of this approach is the ability to create transactions between the databases. Instead of having multiple product management systems and multiple people management systems or solutions, creating a single way to realize a transaction between an individual in the People database (wherever their information might have been extracted from) and an item in the Products database (whichever part of the museum that product emanated from) is a tremendous savings in time and simplification of process. We have only begun to develop these transactional capabilities, but they are fairly easy to realize on the web, and their power quickly becomes apparent.

There are many wrinkles in this structure that need consideration. Some of the information that populates these seven building blocks exists in database applications already, and it can be rationalized and harvested easily. Some of it, though, is not and has never been organized. The whole mass of interpretive content, occasional publications, educator's guides, books, journals, articles by staff members, and other documentary content that together forms the building block Publications does not have easy structures that one can key off of. Some areas of the museum have underdeveloped or disorganized information management tools—the calendar was one such area in our museum—and the core building block may serve as the structure for the whole and the primary point of data entry. Finally, some of the building blocks themselves end up being collectors of information that needs to be re-distributed out to our various software solutions. The People database is a case in point here. When someone buys a product from the museum, the system checks to see if they are already in the People database. If they are, the transaction proceeds. If they are not, their name is added to the People database before proceeding. Once it is there, depending on the transaction, it may be that the membership program, the aspect of the store system that tracks shipping, or the educational program the person has signed up for will want to have their personal data stored in its own format. Nearly all of these challenges turn out to be things that strengthen our own ability to manage our information.

Mystic Seaport is still in the initial stages of realizing this data architecture, but the results realized to date in the areas of managing all of the museum's information in an efficient manner have been very successful. Indeed, the biggest challenges that we have faced in moving to this perspective have had to do with our own ability to understand the tremendous positive implications for our work rather than anything technical. From the technical perspective, most of what we are undertaking is quite mundane. The web has served as a very friendly development platform both from the point of view of creating and using the tools that we need to work with the seven building blocks and from the point of view of being a neutral place outside any particular software application, departmental sway, or the usual vertical structures that characterize museum organization.