11 Chapter 11. The Organizing System Roadmap

Robert J. Glushko

Table of Contents

11.1. Introduction

11.2. The Organizing System Lifecycle

11.3. Defining and Scoping the Organizing System Domain

11.3.1. Scope and Scale of the Collection

11.3.2. Number and Nature of Users

11.3.3. Expected Lifetime

11.3.4. Physical or Technological Environment

11.3.5. Relationship to Other Organizing Systems

11.4. Identifying Requirements for an Organizing System

11.4.1. Requirements for Interactions

11.4.2. About the Nature and Extent of Resource Description

11.4.3. About Intentional Arrangement

11.4.4. Dealing with Conflicting Requirements

11.5. Designing and Implementing an Organizing System

11.5.1. Choosing Scope- and Scale-Appropriate Technology

11.5.2. Architectural Thinking

11.5.3. Distinguishing Access from Control

11.5.4. Standardization and Legacy Considerations

11.6. Operating and Maintaining an Organizing System

11.6.1. Resource Perspective

11.6.2. Properties, Principles and Technology Perspective

11.7. Key Points in Chapter Eleven

Introduction

Chapter 1, Foundations for Organizing Systems defined an organizing system as “an intentionally arranged collection of resources and the interactions they support.” An organizing system emerges as the result of decisions about what is organized, why it is organized, how much it is organized, when it is organized, and how or by whom it is organized. These decisions and the tradeoffs they embody are manifested in the four common activities of organizing systemsselecting resources, organizing them, designing and supporting interactions with them, and maintaining themwhich we described in Chapter 2. Chapters 4-10 progressively explained each of the parts of the organizing system: resources, resource descriptions, resource categories and collections, and interactions with resourcesintroducing additional concepts and methods associated with each of these parts.

Along the way we described many types of organizing systems. Sometimes we discussed broad categories of organizing systems, like those for libraries, museums, business information systems, and compositions of web-based services. At other times we described specific instances of organizing systems, like those in the Seed Library, the Flickr photo sharing site, Amazon’s drop shipment store, and your home kitchen or closet.

We can now build on the foundation created by Chapters 1-10 to create a “roadmap” that organizes and summarizes the design issues and choices that emerge during an organizing system’s lifecycle. These design choices follow patterns that help us understand existing organizing systems better, while also suggesting how to invent new ones by making a different set of design choices.

The roadmap is extensively annotated with references to the preceding chapters where the issues and choices mentioned in the roadmap were introduced and discussed in detail. We will use this roadmap to analyze a variety of case study examples in Chapter 12, Case Studies, and to explore the “design neighborhood” around each of them. The design questions from Chapter 1, Foundations for Organizing Systems serve as a template to give each case study the same structure, which we hope enables instructors, students, and others who read this book to add to this collection of case studies by contributing their own at DisciplineOfOrganizing.org.

Navigating This Chapter

We begin with a look at the section called “The Organizing System Lifecycle” which proposes four phases, each of which is discussed in its own section. The first phase, which largely determines the extent and complexity of the resource descriptions needed for organizing and interactions, is the section called “Defining and Scoping the Organizing System Domain”. The second phase, which is highly shaped by economic factors and technology constraints or choices, is the section called “Identifying Requirements for an Organizing System”. the section called “Designing and Implementing an Organizing System”, emphasizes the need for clearly separating requirements from implementation, a principle we call architectural thinking. The final phase is discussed in the section called “Operating and Maintaining an Organizing System”, where we distinguish the maintenance of specific resources and descriptions from the maintenance of the system as a whole.

The Organizing System Lifecycle

System lifecycle models exhibit great variety; for our purposes it suffices to use a generic four-phase model that distinguishes a domain definition and scoping phase, a requirements phase, a design and implementation phase, and an operational and maintenance phase. These phases are brief and mostly inseparable for some simple organizing systems, more sequential for others, and more systematic and iterative for complex organizing systems.

Most of the specific decisions that must be made for an organizing system are strongly shaped by the initial decisions about its domain, scope (the breadth or variety of the resources), and scale (the number of resource instances). In organizing systems with limited scope and scale, most of these decisions are made in an informal, unanalyzed, and holistic manner. For example, when we arrange our bookshelves or closets it is not necessary to think explicitly about scoping, requirements, design, implementation, and operational phases. For complex organizing systems, however, especially those in information-intensive domains, it is important to follow a more systematic methodology.

Initial decisions about scope and requirements can create lasting technology and process legacies that impact operational efficiency and flexibility. They can also have profound and unforeseen ramifications for the users of the system and other people affected by the work the system enables. A rigorous, well-documented planning process can help organizers minimize unfair and ineffective outcomes, justify their difficult tradeoffs and decisions, and figure out what went wrong so they can learn from their mistakes.

The consequences of releasing technical systems and tools into the world always include social, business, political, and legal dimensions in addition to technical ones. Some of these implications are due to the context in which the system will operate (the section called “Implementing Interactions”). Others are due to the fact that the work of organizing system designers, architects, and developers is shaped by their experiences, values, beliefs, and circumstances—the often hidden constraints and influences of their social position, education, cultural context, and mental models of the world. Inevitably, the work of information professionals involves “carving up the world at its joints,” creating classifications, models, and architectures that support interactions with resources. In practice this often translates to creating artificial “joints” where none truly exist, which will always favor some and injure others. No modeling is ever completely faithful to reality for all people with all experiences (nor is it intended to be), so those people not considered target users for a system, or who have unique circumstances, may end up feeling slighted or ignored and may actually suffer as a result.

Defining and Scoping the Organizing System Domain

The most fundamental decision for an organizing system is defining its domain, the set or type of resources that are being organized. This is why “What is Being Organized?” (the section called “What Is Being Organized?”) was the first of the design decisions we introduced in Chapter 1, Foundations for Organizing Systems.

We refine how we think about an organizing system domain by breaking it down into five interrelated aspects:

the scope and scale of the collection

the number and nature of users

the time span or lifetime over which the organizing system will operate

the physical or technological environment in which the organizing system is situated

the relationship of the organizing system to other ones that overlap with it in domain or scope

Addressing these issues is a prerequisite for prioritizing requirements for the organizing system, proposing the principles of its design, and implementing the organizing system.

Scope and Scale of the Collection

The scope of a collection is the dominant factor in the design of an organizing system, because it largely determines the extent and complexity of the resource descriptions needed by organizing principles and interactions (the section called “Scope, Scale, and Resource Description”). The impact of broad scope arises more from the heterogeneity of the resources in a collection than its absolute scale. It takes more effort to manage a broad and large collection than a narrow and small one; it takes less effort to manage a large collection if it has a narrow scope. A cattle ranch can get by with just one worker for every thousand cows, unlike zoos, which typically have a small number of instances of many types of animals. A zoo needs many more workers because each animal type and sometimes even individual animals can have distinct requirements for their arrangement and care.

Consider a business information system being designed to contain millions of highly structured and similar instances of a small number of related resource types, such as purchase orders and their corresponding invoices.[623] The analysis to determine the appropriate properties and principles for resource description and organization is straightforward, and any order or invoice is an equally good instance to study.[624]

Contrast this large but very narrow collection with a small but very broad one that contains a thousand highly variable instances of dozens of different resource types. This heterogeneity makes it difficult to determine if an instance is representative of its resource type, and every resource might need to be analyzed. This variability implies a large and diverse set of resource descriptions where individual resource instances might not be described with much precision because it costs too much to do it manually (the section called “Resource Description by Professionals”). We can extrapolate to understand why organizing systems whose resource collections are both broad and deep, like those of Amazon or eBay, have come to rely on machine learning techniques to identify description properties and construct resource taxonomies (the section called “Automated and Computational Resource Description”, the section called “Categories Created by Clustering”).[625]

A partial remedy or compromise when the resource instances are highly dissimilar is to define resource types more broadly or abstractly, reducing the overall number of types. We illustrated this approach in the section called “Principles Embodied in the Classification Scheme” when we contrasted how kitchen goods might be categorized broadly in a department store but much more precisely in a wholesale kitchen supply store. The broader categories in the department store blur many of the differences between instances, but in doing so yield a small set of common properties that can be used to describe them. Because these common properties will be at a higher level of abstraction, using them to describe resources will require less expertise and probably less effort (the section called “Scope, Scale, and Resource Description”, the section called “Category Abstraction and Granularity”). However, this comes at a cost: Poets, painters, composers, sculptors, technical writers, and programmers all create resources, but describing all of them with a “creator” property, as the Dublin Core requires, loses a great deal of precision.

Challenges caused by the scale of a collection are often related to constraints imposed by the physical or technological environment in which the collection exists that limit how large the collection can be or how it can be organized. (See the section called “Organizing Physical Resources”) Only a few dozen books can fit on a small bookshelf but thousands of books can fit in your two-car garage, which is a typical size because most people and families do not have more than two cars. On the other hand, if you are a Hollywood mogul, superstar athlete, or sultan with a collection of hundreds of cars, a two-car garage is orders of magnitudes too small to store your collection.[626] Even collections of digital things can be limited in size by their technological environment, which you might have discovered when you ran out of space for your songs and photos on your portable media player.

Estimating the ultimate size of a collection at the beginning of an organizing system’s lifecycle can reduce scaling issues related to storage space for the resources or for their descriptions. Other problems of scale are more fundamental. Larger collections need more people to organize and maintain them, creating communication and coordination problems that grow much faster than the collection, especially when the collection is distributed in different locations.

The best way to prevent problems of scope and scale is through standardization. Standardization of resources can take place if they are created by automated means so that every instance conforms to a schema or model (the section called “Implementing Categories Defined by Properties”).[627] Standards for describing bibliographic resources enable libraries to centralize and share much resource description, and using the same standards for resources of diverse types helps address the challenge of broad scope by reducing the need for close monitoring and coordination. Analogous standards for describing information resources, services, or economic activities business, governmental, or scientific information systems to systematically manage hundreds of millions or even billions of transactional records or pieces of data (the section called “Scope, Scale, and Resource Description”).

Number and Nature of Users

An organizing system might have only one user, as when an individual creates and operates an organizing system for a clothes closet, a home bookcase or file cabinet, or for digital files and applications on a personal computer or smart phone. Collections of personal resources are often organized for highly individualized interactions using ad hoc categories that are hard to understand for any other user (the section called “Individual Categories”). Personal collections or collections used by only a small number of people typically contain resources that they themselves selected, which makes the most typical interaction with the organizing system searching for a familiar known resource (the section called “User Requirements”).

At the other extreme, an organizing system can have national or even global scope and have millions or more users like the Library of Congress classification system, the United Nations Standard Products and Services Code, or the Internet Domain Name System. These organizing systems employ systems of institutional categories (the section called “Institutional Categories”) that are designed to support systematically specified and purposeful interactions, often to search for previously unknown resources. In between these extremes are the many kinds of organizing systems created by informal and formal groups, by firms of every size, and by sets of cooperating enterprises like those that carry out supply chains and other information-intensive business processes.

The nature and number of users strongly shapes the contents of an organizing system and the interactions it must be designed to support. (See the section called “User Requirements”) Some generic categories of users that apply in many domains are customers, clients, visitors, operators, and managers. We can adapt the generic interactions supported by most organizing systems (the section called “Determining the Purposes”) to satisfy these generic user types. For example, while most organizing systems allow any type of user to browse or search the collection to discover its content, only operators or managers are likely to have access to information about the browsing and searching activities of customers, clients, or visitors.

Once we have identified the organizing system’s domain more precisely we can refine these generic user categories, classifying users and interactions with more precision. For example, the customers of university libraries are mostly professors and students, while the customers of online stores are mostly shoppers seeking to find something to purchase. Library customers borrow and return resources, often according to different policies for professors and students, whereas online stores might only allow resources to be returned for refunds or exchanges under limited circumstances.

Just as it is with collection scope, the heterogeneity of the user base is more critical than its absolute size. An airport bookstore typically has a narrowly focused collection and treats its customers as generic travelers browsing imprecisely for something to fill their time in the terminal or on the airplane. In contrast, the local public library will have a much broader collection because it has to meet the needs of a more diverse user base than the airport bookstore, and it will support a range of interactions and services targeted to children learning to read, school students, local businesses, retirees, and other categories of users. A company library will focus its collection on its industry segment, making it narrower in coverage than a local or university research library, but it might provide specialized services for marketing, engineering, research, legal, or other departments of the firm.

Each category of users, and indeed each individual user, brings different experiences, goals, and biases into interactions with the organizing system. As a result, organizing systems in the same domain and with nominally the same scope can differ substantially in the resources they contain and the interactions they support for different categories of users. The library for the Centers for Disease Control and the WebMD website both contain information about diseases and symptoms, but the former is primarily organized to support research in public health and the latter is organized for consumers trying to figure out why they are sick and how to get well. These contrasting purposes and targeted users are manifested in different classification systems and descriptive vocabularies.[628]

The designers of these systems do not necessarily share the same biases as their users, and more importantly, they may not always understand them completely or correctly. This is precisely why good design is iterative: successive cycles of evaluation and revision can shape crude, provisional, and misguided ideas into wildly successful ones. But such nimbleness is not always feasible in highly complex, political, or bureaucratic institutional contexts. Even then, as Bowker and Star conclude, transparency is the best corrective for these sorts of design failures. Designers who recognize that their systems have real consequences for real people should commit to an ongoing process of negotiation that enables those affected by the technology to voice and push back against any detrimental effect it might have on them and their communities. This helps set the stage for effective operation and maintenance of the system (the section called “Properties, Principles and Technology Perspective”).

Expected Lifetime

The scope and scale of a collection and the size of its user population are often correlated with the expected lifetime of its organizing system. Because small personal organizing systems are often created in response to a specific situation or to accomplish a specific task, they generally have short lifetimes (the section called “Individual Categories”).

The expected lifetime of the organizing system is not the same as the expected lifetime of the resources it contains because motivations for maintaining resources differ a great deal. (See the section called “Motivations for Maintaining Resources”) As we have just noted, some organizing systems created by individuals are tied to specific short-term tasks, and when the task is completed or changes, the organizing system is no longer needed or must be superseded by a new one. At the other extreme are libraries, museums, archives, and other memory institutions designed to last indefinitely because they exist to preserve valuable and often irreplaceable resources.

However, most business organizing systems contain relatively short-lived resources that arise from and support day-to-day operations, in which case the organizing system has a long expected lifetime with impermanent resources. Finally, just to complete our 2 x 2 matrix, the auction catalog that organizes valuable paintings or other collectibles is a short-lived single-purpose organizing system whose contents are descriptions of resources with long expected lifetimes.

Physical or Technological Environment

An organizing system is often tied to a particular physical or technological environment. A kitchen, closet, card cabinet, airplane cockpit, handheld computer or smartphone, and any other physical environment in which resources are organized provides affordances to be taken advantage of and constraints that must be accommodated by an organizing system (the section called “Affordance and Capability”).[629]

The extent of these physical and technological constraints affects the lifetime of an organizing system because they make it more difficult to adapt to changes in the set of resources being organized or the reasons for their organization. A desk or cabinet with fixed “pigeon holes” or drawers affords less flexible organization than a file cabinet or open shelves. A building with hard-walled offices constrains how people interact and collaborate more than an open floor plan with modular cubicles does. Business processes implemented in a monolithic enterprise software application are tightly coupled; those implemented as a choreography of loosely-coupled web services can often transparently substitute one service provider for another.

Relationship to Other Organizing Systems

The same domain or set of resources can have more than one organizing system, and one organizing system can contain multiple others. The organizing system for books in a library arranges books about cooking according to the Library of Congress or Dewey Decimal classifications and bookstores use the BISAC ones, mostly using cuisine as the primary factor (the section called “Bibliographic Classification”). In turn, cookbooks employ an organizing system for their recipes that arranges them by type of dish, main ingredient, or method of preparation. Within a cookbook, recipes might follow an organizing system that standardizes the order of their component parts like the description, ingredients, and preparation steps.

Sometimes these multiple organizing systems can be designed in coordination so they can function as a single hierarchical, or nested, organizing system in which it is possible to emphasize different levels depending on the user’s task or application. Most books and many documents have an internal structure with chapters and hierarchical headings that enable readers to understand smaller units of content in the context of larger ones (the section called “Structural Relationships within a Resource”). Similarly, a collection of songs can be treated as an album and organized using that level of abstraction for the item, but each of those songs can also be treated as the unit of organization, especially when they are embodied in separate digital files.

Organizing systems overlap and intersect. People and enterprises routinely interact with many different organizing systems because what they do requires them to use resources in ways that cut across context, device, or application boundaries. Just consider how many different organizing systems we use as individuals for managing personal information like contacts, appointments, and messages. As company employees we create and organize information in email, document repositories, spreadsheets, and CRM and ERP systems. Now consider this at an institutional scale in the inter-enterprise interactions among the organizing systems of physicians, hospitals, medical labs, insurance companies, government agencies, and other parties involved in healthcare. Consider how many of these are “mash-ups” and composite services that combine information and resources from independently designed systems.

We have come to expect that the boundaries between organizing systems are often arbitrary and that we should be able to merge or combine them when that would create additional value. It is surely impossible to anticipate all of these ad hoc or dynamic intersections of organizing systems, but it is surely necessary to recognize their inevitability, especially when the organizing systems contain digital information and are implemented using web architectures.

Identifying Requirements for an Organizing System

The two parts of the definition of an organizing system explicitly suggest two categories of requirements, those that specify the intentional arrangement of the resources and those that specify the interactions with the resources. These categories of requirements both depend on resource descriptions, which are implied by but not explicitly called out in the definition of an organizing system.

Because description, arrangement, and interaction are interrelated it is impossible to describe them separately without some redundancy. Nevertheless, in this book we have done that on purpose because taking different perspectives on organizing systems in Chapters 2-10 has enabled us to introduce a broad range of concepts, issues, and methods:

Every organizing system must enable users to interact with its collection of resources (Chapters 3 and 10);

The possible interactions depend primarily on the nature and extent of the descriptions associated with the resources (Chapters 4, 5 and 6);

Intentional arrangement emerges when one or more resource descriptions are used by organizing principles (Chapters 7 and 8);

Different implementations of the same organizing principle can determine the efficiency or effectiveness of the interactions it enables. (Chapter 10).

If you are creating a personal organizing system or otherwise small-scale one with only a small number of users, you might think there is little reason to think explicitly about requirements. However, any project benefits from the discipline of being more systematic about its purposes and their priorities. In addition, being explicit about requirements enables traceability and impact analysis. Traceability means being able to relate an interaction or feature of a system to the requirement it satisfies; impact analysis runs the causal link between requirements and features in the opposite direction to assess what or who will be affected if requirements change.[630]

Requirements for Interactions

When we describe interactions in a generic or broad way as we did in Chapter 3, Activities in Organizing Systems we see that all organizing systems have some common interactions, but most of the time we want to pay attention to the more specific interactions that are designed to create value in a particular organizing system because of the kind of resources it contains (the section called “Interaction and Value Creation”). The domain, scope, and scale of the organizing system determines which interactions are possible and which ones must be explicitly supported, but the priorities of different interactions are more often determined by decisions about intended users. (See the section called “Number and Nature of Users”.)

For most organizing systems other than personal ones, the set of interactions that are implemented in an organizing system is strongly determined by business model considerations, funding levels, or other economic factors. For-profit firms often differentiate themselves by the number and quality of the interactions they support with their resources, some by supporting many of them and some by supporting a minimal number. This differentiation is strongly shaped by and also shapes user preferences; some people prefer self-service or unmediated interactions, while others prefer full service and mediated interactions.[631] Non-profit institutions like public libraries and museums are also subject to these constraints, but unfortunately they have fewer options for adjusting service levels or changing their targeted user populations when their funding is reduced.[632]

Some requirements for interactions come along with technology requirements, to have resources in a particular format, to conform to a particular specification or standard in order to operate in some technology environment, or to interoperate with other parties or their organizing systems.

An essential requirement in every organizing system is ensuring that the supported interactions can be discovered and invoked by their intended users. In organizing systems with physical resources, good designers enhance the inherent affordances of resources with navigation and orientation aids that direct users to points of interactions (the section called “Affordance and Capability”). With digital resources and information-intensive organizing systems, interactions are not immediately perceivable, and poor design can create overly complicated user interfaces in which many interactions are never discovered and thus never used.

It is tricky to compare the overall capabilities of organizing systems in terms of the number or variety of their interactions because what matters more is how much value they create. Organizing systems with active resources can create value on their own without an explicit user interaction (the section called “Active or Operant Resources”). Other organizing systems exploit stored, computed, or contextual information to create value by eliminating the need for user interactions, such as location-based smartphone apps that push information to you when you are near some particular location or some person you know (the section called “Affordance and Capability”).[633]

About the Nature and Extent of Resource Description

Interactions with resources within an organizing system often depend on descriptions of individual resources or descriptions of the collections that contain them. In the bibliographic domain, generic or common interactions make use of descriptions that can be associated with almost any type of resource, such as the name, creator, and creation date.[634]

For example, any resource with a sortable name or identifier can be arranged alphabetically to enable it to be easily found, and any resource with a creation date can be discovered by a “what’s new” query to a resource collection.

Different types of resources must have differentiating properties, otherwise there would be no reason to distinguish them as different types. These resource properties can be recorded in the terms of a description language to support one or more interactions or to answer one or more questions. Simply put, choices about the nature and extent of resource description depend on which interactions or questions are most frequent or important (the section called “Describing Instances or Describing Collections”). If a particular property of a resource has no interactions that depend on it, there is no need to describe it. However, if an interaction depends on a description of a particular resource property, a missing description or one of inadequate precision and granularity means that the interaction will be impossible or inefficient to carry out because the resource will need to be further analyzed to create or extract the required description. An ISBN is a sufficient description to find a book in a directory, but if the ISBN is the only description associated with the book you will not be able to tell who wrote it. The tradeoffs imposed by the extent and timing of resource description have been a recurring theme in this book, with the tradeoff between recall and precision being the most salient (the section called “When Is It Being Organized?”, the section called “Affordance and Capability”, the section called “Category Abstraction and Granularity”, the section called “The Recall / Precision Tradeoff”).

The properties of resources that are easiest to describe are not always the most useful ones, especially for information resources. Anyone can determine the number of pages in a book, but often only a skilled cataloger can accurately describe what the book is about, a far more important property. (the section called ““Description” as an Inclusive Term” and the section called “The Limits of Property-Based Categorization”) For non-text information resources this problem is magnified because the content is often in a semantically opaque format that it optimized for the devices that creates and processes it but which cannot usefully be analyzed by people. (the section called “The Semantic Gap” and the section called “Describing Non-text Resources”)

Business strategy and economics strongly influence the extent of resource description. In many museums and archives there are not enough trained people and time to describe every pottery fragment or document, and many resources are described only at an aggregate level. In contrast, some people argue that the explosion of content in physical and digital form mandates significant investment in descriptions that facilitate resource discovery in a crowded marketplace.[635]

Automated and computerized processes can create the resource descriptions in an organizing system and their use is primarily driven by scale (the section called “Automated and Computational Resource Description”). Search engines index web pages and analyze their link structures because it would be impossible to treat the web as a traditional library and organize it by human effort. The benefits of digital cameras, video recorders, and similar devices would be far fewer if people had to manually identify and describe each resource when creating it. Instead, these devices can automatically assign some contextual metadata. Similarly, competitive pressures on vendors to provide real-time and context-sensitive information services mandate automated collection of contextual information like location from mobile phones, portable book readers and tablet computers.

Color Coded Library

image

Because he is presumably familiar with the contents of all of his books, interaction designer Juhan Sonin organized his library according to their spine colors. This organizing principle is a highly individual and aesthetic one, but it would probably not appeal to people unfamiliar with the collection and would bring chaos to a library of larger size.

(Photo by See-ming Lee. Creative Commons CC-BY-SA-2.0 license.)

We might seek some optimal degree of description given some set of requirements or purposes for an organizing system and some estimate of the organizing effort that could be applied; in practice this is elusive for two reasons, both relating to scope and scale. First, as the number of users of an organizing system increases, it becomes more difficult to identify and anticipate all its possible purposes and constraints it must satisfy. Even if most users share the goals for the organizing system, any particular user might have some additional specialized use for some attributes or relationships that would require more description to satisfy.[636]

Second, even if it were possible to implement some optimal degree of description in a particular organizing system, we would still encounter problems when multiple organizing systems exist in the same domain or in domains that intersect across context, device, or application boundaries. Since organizing systems are designed and evolve to satisfy the specific requirements of their particular context, companies will often describe the same resources differently, which creates integration and interoperability problems when companies need to exchange and combine information resources (the section called “Transforming Resources for Interactions”).

About Intentional Arrangement

Organizing principles depend on resource descriptions, so requirements for the former are always intertwined with those for the latter. Specifying requirements for the intentional arrangement of resources is analogous to specifying why and how resource categories can be created (the section called “Principles for Creating Categories”). In turn, the creation of resource categories often becomes a question about the number and kind of resource properties that might be analyzed and exploited by organizing principles.

We noted that there is a continuum of category formation that ranges from minimal use of resource properties to more rigorous use of multiple properties, and finally to statistical or composite use of multiple properties, some of which are induced or inferred rather than explicit. The simplest principle for defining a category is by enumeration, just putting the resources into a set without any specification of any properties they might share. The enumerated resources might very well have common properties, but the principle of enumeration ignores them; the only property that matters for that principle is that the resources are in the same set. This corresponds to the simplest principle of intentional arrangement, that of collocation, just putting the resources in the same location without any additional organization.

Collocated resources often acquire some additional arrangement as a result of their use; consider how the books, papers, or other resources gathered for some writing project often end up in piles in your office or on your desk close to your work area. For a small collection, the proximity-to-use organizing principle is the easiest way to satisfy a requirement to minimize the time to find frequently used resources.

As we have often seen, the scope and scale of the organizing system is a dominant design consideration and it applies to principles of resource arrangement too. The collocation principle of arrangement is sufficient for small resource collections because it is not necessary to define the optimal organization if the time to find any particular resource is short even for an inefficient search method of scanning the entire collection. Using the extrinsic property of frequency of use makes search slightly more efficient, but only in organizing systems where the user population is small or interacts with the resources in similar ways. Otherwise, arranging resources to facilitate their frequent access for some users would hinder other users who never use them. Imagine if you shared your office desk with someone who works all night on other writing projects and leaves his frequently used resources in piles close to his work area—which becomes your work area in the morning.

Larger resource collections usually require multiple organizing principles to manage the complexity that emerges when more users and more varied interactions must be supported. A valet parking lot might organize cars only by size to make optimal use of limited space when parking and fetching them, but when cars are organized for sale they would be organized by price, performance, seating capacity, manufacturer, and many other properties. It is essential to establish the priority of users and interactions because these requirements determine the order in which the principles are applied to arrange the resources. This ordering creates a logical resource hierarchy that affects the efficiency of interactions and the maintenance of the organizing system over time.

Information resources are invariably challenging to arrange because their aboutness is not an easily perceived property and because of the open-ended purposes they can serve. Information collections with broad scope most often use a standard system of bibliographic classification (the section called “Bibliographic Classification”). In contrast, special libraries have narrower collections that need to support domain-specific interactions for a relatively small set of users, and as a result they require more specialized organizational schemes.[637] The principles for resource arrangement in large firms of every type are often required to conform with laws and regulations for accounting, taxes, human resources, data retention and non retention, access control, and other functions. (See the section called “Governance in Business Organizing Systems”, the section called “Mandated Classifications”)

Dealing with Conflicting Requirements

Any individual, group, or enterprise can create an organizing system that meets their specific requirements, but once this organizing system involves two or more parties with different requirements, there is a potential for conflict. Roommates or spouses sometimes argue about how to organize items in the kitchen, in the refrigerator, or in some other shared space. To a person who arranges spices alphabetically and condiment jars by size, arranging them according to cuisine or frequency of use makes no sense. Similarly, if you are the sole user of a Dropbox or other cloud storage account, you can organize it any way you want. You can use any number of folders that need only make sense to you, or you can leave everything unorganized in a single folder. However, if you share the Dropbox account with another person, they are likely to have different organizational needs or preferences. Perhaps you tend to organize resources by file type, while they prefer to organize resources by topic or project.

A small number of people can often agree on an organizing system that meets the needs of each participant through informal negotiations. The potential for conflict increases when more people are involved, and “bottom-up” ad hoc negotiations to resolve every disagreement between every pair of participants just are not feasible. In many domains conflicts are avoided or suppressed because the parties have developed or agreed to conform to standards (the section called “Classification and Standardization”). Nevertheless, conflicts in organizing principles for large-scale organizing systems are often resolved by parties with the legal authority or economic power to impose a solution on all the participants in a “top-down” manner.[638]

Designing and Implementing an Organizing System

Requirements define what must be done but NOT how to do it; that’s the role of the design and implementation phases. Being explicit about requirements and the intended scope and scale of an organizing system before moving onto these phases in an organizing system’s lifecycle avoids two problems. The first is taking a narrow and short-term focus on the initial resources in a collection, which might not be representative of the collection when it reaches its planned scope and scale. This can result in overly customized and inflexible resource descriptions or arrangements that cannot easily accommodate the future growth of the collection. A second problem, often a corollary of the first, is not separating design principles from their implementation in some specific environment or technology.

Choosing Scope- and Scale-Appropriate Technology

A simple organizing system to satisfy personal record keeping or some short-lived information management requirements can be implemented using folders and files on a personal computer or by using “off the shelf” generic software such as web forms, spreadsheets, databases, and wikis. Other simple organizing systems run as applications on smart phones. Some small amount of configuration, scripting, structuring or programming might be involved, but in many cases this work can be done in an ad hoc manner. The low initial cost to get started with these kinds of applications must be weighed against the possible cost of having to redo a lot of the work later because the resources and the resource descriptions might not be easily exported to new ones.

More capable organizing systems that enable the persistent storage and efficient retrieval of large amounts of structured information resources generally require additional design and implementation efforts. Flat word processing files and spreadsheets are not adequate. Instead, XML document models and database schemas often must be developed to ensure more control of and validation of the information content and its descriptions. Software for version and configuration management, security and access control, query and transformation, and for other functions and services must also be developed to implement the organizing system.

Technology for organizing systems will always evolve to enable new capabilities. For example, cloud computing and storage are radically changing the scale of organizing systems and the accessibility of the information they contain. It might be possible to implement these capabilities and services to an organizing system in an incremental fashion with informal design and implementation methods. If information models, processing logic, business rules and other constraints are encoded in the software without explicit traceability to requirements and design decisions the organizing system will be difficult to maintain if the context, scope or requirements change. This is why we have repeatedly emphasized the importance of architectural thinking about organizing systems, beginning in the section called “The Concept of “Organizing Principle” where we proposed that organizing principles should ideally be expressed in a way that did not assume how they would be implemented. (See also the section called ““Information Architecture” and Organizing Systems”, the section called “Classification vs. Physical Arrangement”, and the section called “Introduction”)

Architectural Thinking

Much of the advice about designing and implementing an organizing system can be summarized as “architectural thinking,” introduced in the section called “The Concept of “Organizing Principle”. The overall purpose of architectural thinking is to separate design issues from implementation ones to make a system more robust and flexible. Architectural thinking leads to more modularity and abstraction in design, making it easier to change an implementation to satisfy new requirements or to take advantage of new technologies or procedures. It is also important to think architecturally about the design of the vocabularies and schemas for resource description and of classification systems to leave room for expansion to accommodate new resource types (the section called “Implementing Categories” and the section called “Principles for Maintaining the Classification over Time”). Doing so is easier if the descriptions are logically and physically distinct from the resources they describe. A checklist the brings together useful principles and processes for architectural thinking from all parts of this book is in the nearby sidebar.

Principles and Processes for Architectural Thinking

Explicitly define the purposes and users of the organizing system, recognizing that users might not agree on purposes or their priorities (the section called “Why Is It Being Organized?”).

Select resources (the section called “Selection Criteria”) and design interactions (the section called “Interaction and Value Creation”) to support the primary or highest priority users.

Specify information and interaction requirements in a conceptual and technology-neutral way (the section called “The Concept of “Organizing Principle”) that conforms as much as possible to domain standards, schemas, or vocabularies (the section called “Classification and Standardization”).

Implement user interactions with design patterns to make them more discoverable, usable, and effective (the section called ““Information Architecture” and Organizing Systems”).

Follow principles for good names (the section called “Choosing Good Names and Identifiers”) and good resource descriptions (the section called “Principles of Good Description”).

Make an informed decision about the tradeoff between flexibility and complexity; a simpler system might be easier to adapt (the section called “Principles for Maintaining the Classification over Time”).

Make design and technology decisions consistent with the expected life of the organizing system (the section called “Operating and Maintaining an Organizing System”).

Stop and Think: What is a Library?

The word “library” has several meanings that differ in how much architectural thinking they embody. When you tell someone you will meet them at the library for a cup of coffee and a study session it is a specific physical place. At other times you might use a more abstract notion of a library as an organizing system with a predictable type of collection, resource arrangement, and supported interactions. Both meanings are important for a city creating a new library. How would you ensure that both are considered in an effective way?

Nevertheless, architectural thinking requires more careful analysis of resources and implementation alternatives, and most people do not think this way, especially for personal and informal organizing systems. You can imagine that someone might arrange a collection of paperback books in a small bookcase whose shelf height and width were perfectly suited for the paperbacks they currently own. However, this organizing system would not work at all for large format books, and a paperback could not be added to the collection unless one was purged from the collection. It would be more sensible to start with a bigger bookcase with adjustable shelves so that the organizing system would have a longer lifetime.

You might think that large institutional organizing systems would avoid these problems caused by tying a collection too tightly to the physical environment in which it is initially organized, but sometimes they do not. A famous example involves the art collection of the Barnes Foundation, which had to keep its paintings in the exact same crowded arrangements when the museum made a controversial move from a small building to a larger one because the donor had mandated that the paintings never be moved from their original settings. (See the sidebar, The Barnes Collection).

For digital resources, inexpensive storage and high bandwidth have largely eliminated capacity as a constraint for organizing systems, with an exception for big data, which is defined as a collection of data that is too big to be managed by typical database software and hardware architectures.[639] Even so, big data collections are often large but homogeneous, so their scale is not their most important challenge from an organizing system perspective (the section called “Scope and Scale of the Collection”).

The Barnes Collection

Albert Barnes was a chemist who made a fortune inventing a preventive treatment for gonorrhea and who then amassed perhaps the greatest private art collection ever, one that contained over 800 paintings by artists like Picasso, Renoir, Matisse, van Gogh, and Cezanne. In 1922 Barnes built a museum for his collection in his residential neighborhood in Merion, PA, a suburb of Philadelphia. Barnes did not open his collection to the public and in his will mandated that the collection never be moved, loaned, or sold.

In the decades after Barnes died in 1951 the Merion museum needed extensive repairs and security upgrades, and some people suggested that its remote location and access restrictions jeopardized its financial viability. However, a proposal to relocate the collection to Philadelphia seemingly violated the terms of the Barnes will.

A legal fight dragged on for decades. Finally in 2004 a judge ruled that the collection could be moved to Philadelphia, but only if the new museum contained exact copies of the gallery rooms of the original museum and arranged the paintings exactly as they were in Merion. The new museum building, opened in 2012, is ten times larger than the old one, but the collection takes up the same space as it did in Merion. The other 90% of the building is occupied by an auditorium, offices, classrooms, a gift shop, and other space that contains none of the collection.[640]

Distinguishing Access from Control

Because large resource collections are often used for multiple purposes by many different people or projects, they illustrate another important architectural issue for collections of digital resources. A requirement for access to resources does not imply a need to directly own or control them, and information-intensive and web-based businesses have increasingly adopted organizing system designs that involve storage of digital resources in the cloud, licensing of globally distributed resources, and outsourcing of information services. Designs that use these architectural concepts can realize functional and quality improvements because the location and identity of the service provider is hidden by an abstraction layer (the section called “Value Creation with Physical Resources”, the section called “Distinguish Identifying and Resolving”). However, separating access from ownership has been a cultural challenge for some libraries and museums whose institutional identities emphasize the resources they directly control and the physical buildings in which they control them.[641]

Standardization and Legacy Considerations

As we noted with the Barnes Collection, a building becomes old and outdated over time. The technology used in digital organizing systems becomes obsolete faster than physical buildings do. The best way to slow the inevitable transformation of today’s cutting edge technology to tomorrow’s legacy technology is to design with standard data formats, description vocabularies and schemas, and classification systems unless you have specific requirements that preclude these choices.

Even a requirement to interoperate with an organizing system that uses proprietary or non-standard specifications can usually be satisfied by transforming from a standard format (the section called “Institutional Semantics”, the section called “Implementing Interactions”). Similarly, it is better to design the APIs and data feeds of an organizing system in a generic or standard way that abstracts from their hidden implementation. This design principle makes it easier for external users to understand the supported interactions, and also prevents disclosure of any aspects of resource description or organization that provide competitive advantage. For example, the way in which a business classifies products, suppliers, customers, or employees can be competitively important.

Two important design questions that arise with data transformation or conversion, whether it is required by a technology upgrade or an interoperability requirement, are when to do it and where to do it. The job of converting all the resources in a collection can typically be outsourced to a firm that specializes in format conversion or resource description, and a batch or pre-emptive conversion of an entire collection enables an upgraded or new organizing system to operate more efficiently when it is not distracted by ongoing conversion activity. On the other hand, if resources vary greatly in their frequency of use, a “do-it-yourself on-demand” method is probably more cost effective as long as the conversion does not impact the interactions that need to be supported.

Operating and Maintaining an Organizing System

After the organizing system has been designed and implemented it can be put into its operation and maintenance phases. We will look at these from two perspectives, first from the point of view of individual resources, and then from the point of view of the organizing system’s design and implementation. These two perspectives are not always clearly distinguished. Curation, for example, is often used to describe actions taken to maintain individual resources as well as those that result in new arrangements of them.

Resource Perspective

Sometimes an organizing system is implemented with its organizing structures and relationships waiting to be populated by resources as they are acquired and described. The scope and scale of the organizing system shapes how the descriptions are created and how the descriptions are then used to assign resources to the logical or physical containers of the organizing system. The most important decisions to be made at this point involve determining an appropriate mix of methods for creating the resource descriptions, because their cost, quality, consistency, completeness, and semantic richness depends on which human or computational agents do the work (the section called “Creating Resource Descriptions”).

For web-based and consumer-focused organizing systems, it is tempting to rely on users to assign descriptions, tags, or ratings to resources (the section called “Tagging of Web-based Resources”). Some of these systems attempt to improve the quality and precision of these descriptions by providing forms, controlled vocabularies, or suggestions. Finding a balance is tricky; too much direction and control is demotivating to uncompensated volunteer describers, and too little of it results in the proverbial “tag soup.”

An essential operational and maintenance activity is evaluation of resource descriptions, first with respect to the time and process by which they are created, and second with respect to how and when they support the designed interactions (the section called “Evaluating Resource Descriptions”).

Some organizing systems are initiated with a fixed set of resources that will not change in any way. For example, in an archive as most narrowly defined, neither the individual resources nor the organization of the collection as a whole will change. If an archive of Abraham Lincoln letters is established, we know that Lincoln will never revise any letters or write any new ones, and any new classifications or descriptions devised by people studying the archive will not be used to rearrange the letters.

Most organizing systems, however, need to support ongoing interactions with a collection that changes over time as new resources enter the collection and old ones leave. These selection and collection management processes are explicit in libraries, museums and similar institutions that maintain collections to satisfy the changing needs and preferences of their user communities (the section called “Looking “Upstream” and “Downstream” to Select Resources”).

Properties, Principles and Technology Perspective

It is useful to consider how an organizing system as a whole is operated and maintained over time. We can analyze how the system’s organizing properties, principles and technology might change, and we can roughly order different types of change according to their overall impact.

The most predictable maintenance activities for an organizing system with an expected long lifetime (the section called “Expected Lifetime”) are incremental changes in description vocabularies and classification schemes (the section called “Principles for Maintaining the Classification over Time”). These need to evolve when new instances or contexts require additional properties to maintain the distinctions between types of resources, but the basic principles embodied in the organizing systems are not affected.

Incremental category maintenance takes place even in personal organizing systems where the categories are not always explicit. The collection of clothes in a college student’s closet and the categories and properties for arranging them will change somewhat when he graduates and takes a job in a downtown office building where he needs to dress more formally than he did as a student. He will learn that despite the common term in the category name, “student casual” and “business casual” do not contain the same sets of resources.

Category maintenance is an ongoing activity in institutional organizing systems. The most commonly used bibliographic classification systems all have numbering and naming schemes that allow for subdivision and extension to create new subcategories to accommodate resources about new fields of knowledge and technology.

As another example, the Association for Computing Machinery(ACM) professional society created a keyword classification in 1964 to organize articles in its many publications, but relentless change in the computing field driven by Moore’s Law has required the ACM to significantly revise the system almost every decade.[642]

In contrast, changes in business organizing systems are more likely to be driven by economic factors. Resource properties for managing collections of resource and the information that describes them often change over time as a result of new products and services, mergers and acquisitions, or refined customer segmentation. More substantial changes in business organizing systems reflect the need to comply with laws and regulations that impose new requirements for tracing money flows or transactions. These mandated classifications and processes might require new organizing principles, not just incremental properties (the section called “Mandated Classifications”).

The choice of implementation technology influences how easy it is to handle these types of changes in organizing systems. In databases this problem is known as “schema migration.” With XML implementations, schemas can be designed with “extension” or “codelist” elements to enable changes that will not invalidate existing information. Business processes that are driven by “executable specifications” like the Business Process Execution Language(BPEL) can be easily modified because the BPEL XML instance is used to configure the software that carries out the process it describes.[643]

Another very predictable type of activity over time with organizing systems is a technology upgrade that improves its quality or capabilities without affecting the organizing principles. A student might replace his handwritten lecture notes with typed notes on a laptop or tablet computer but not significantly change the way the notes are organized.

Institutional organizing systems are adopting tiered storage systems that automatically move resources between different types of storage media to meet performance, availability and recovery requirements. For example, firms with high financial impact of downtime like banks run critical organizing systems with copies in “failsafe” or “hot” modes that are synchronized with the production environments to prevent any interruptions in information access if the latter are disrupted. On the other hand, resources needed for regulatory compliance can be kept on lower cost disk storage.

The most challenging kinds of maintenance activities for organizing systems involve changes to the principles for arranging resources along with changes in the implementing technology. An example is the ambitious effort to introduce semantic web and linked data concepts in bibliographic organizing systems (the section called “Bibliographic Organizing Systems”, the section called “The Semantic Web World”). And change comes faster to businesses than to libraries and museums. New technologies can have a disruptive impact on business organizing system, forcing major changes to enable strategy changes that involve faster finding, retrieval, or delivery of informational or physical goods.[644]

Sometimes major changes to organizing principles and technologies can be introduced incrementally, with changes “rolled out” to different sets of resources or user groups during a transition period. However, sometimes the changes are inherently ”all or none” because it is impossible to have two conflicting organizing systems operating in the same context. An easy to understand example of an organizing system that changed radically is the system governing which side of the road you drive on, which was changed in Samoa in 2009. (See the sidebar, Driving in Samoa).

Driving in Samoa

Whether you travel by bus, car, or bicycle, you always keep to one side of the road. The convention of driving on either the right side or the left side is a legal standard that everyone takes for granted. However, you must follow it to ensure safe driving and avoid collisions and crashes.

This standard of which side of the road you drive on was not decided arbitrarily, but rather, it was adopted as a result of history, convention, and the need for organization. If you were the only person to use the road, you could choose to travel on any side you wanted, even travel right down the middle. As soon as more than one person needs to use the same road, the risk of collisions compels the creation of a coordinating standard.

In 2009, the government of Samoa took the rare step of changing the side of the road standard from driving on the right to driving on the left. The original standard reflected the influence of German colonization in the early 1900s. However, Samoa is both geographically close to and economically intertwined with Australia and New Zealand, former British colonies that follow the British convention of driving on the left side. This proximity gives Samoa access to a nearby source of used cars that would be attractive to Samoa’s relatively poor population. So, the Samoan government decided to use its authority to change the driving standard so that more of its people could afford to buy cars.

As one could imagine, this decision was not implemented without controversy and opposition. While the decision benefited people currently without cars, it negatively affected those who already owned them. After a switch like this, what happens to the current market value of the thousands of cars designed to drive on the right? Opponents also claimed that the switch would cause unprecedented safety hazards. If even a small fraction of drivers were not able to immediately get the hang of driving on the other side, the accident rate could increase tremendously. Imagine the current pool of buses designed with doors that open on the right hand sidewould they now let passengers out in the middle of the street? Who would pay to have the buses modified to put doors on the left hand side?[645]

Key Points in Chapter Eleven

11.7.1. What three initial characteristics of an organizing system influence most of the decisions about that organizing system?

11.7.2. What is the effect of broad scope in an organizing system?

11.7.3. What is a practical effect of increasing collection size?

11.7.4. How do you avoid problems of scope and scale?

11.7.5. What is an effect of a heterogeneous user community?

11.7.6. How can designers mitigate possible negative consequences of the system and technology they design?

11.7.7. What is the single biggest factor affecting the implementation of interactions?

11.7.8. What is the most essential requirement of interactions?

11.7.9. What is the role of computational agents in the creation and consumption of resource descriptions?

11.7.10. What is the relationship between organizing principles and resource descriptions?

11.7.11. What characteristics of resource descriptions impede growth?

11.7.12. What are the advantages of architectural thinking?

11.7.13. What is big data?

11.7.14. What are the most predictable maintenance activities?

11.7.15. What changes in organizing systems make maintenance especially difficult?

11.7.16. What six questions should be asked when approaching any organizing system?

11.7.1.

What three initial characteristics of an organizing system influence most of the decisions about that organizing system?

 

Most of the specific decisions that must be made for an organizing system are shaped by the initial decisions about its domain, scope, and scale.

(See the section called “The Organizing System Lifecycle”)

11.7.2.

What is the effect of broad scope in an organizing system?

 

The impact of broad scope arises more from the heterogeneity of the resources and users in a collection rather than from their absolute number.

(See the section called “Scope and Scale of the Collection”)

11.7.3.

What is a practical effect of increasing collection size?

 

Larger collections need more people to organize and maintain them, creating communication and coordination problems that grow much faster than the collection.

(See the section called “Scope and Scale of the Collection”)

11.7.4.

How do you avoid problems of scope and scale?

 

Standardization is the best way to prevent problems of scope and scale.

(See the section called “Scope and Scale of the Collection”)

11.7.5.

What is an effect of a heterogeneous user community?

 

Organizing systems in the same domain and with nominally the same scope can differ substantially in the resources they contain and the interactions they support if they have different categories of users.

(See the section called “Number and Nature of Users”)

11.7.6.

How can designers mitigate possible negative consequences of the system and technology they design?

 

Designers who recognize that their systems have real consequences for people should commit to measures of transparency and an ongoing process of negotiation that enables those affected to voice concerns related to any detrimental effects the technology might have on them and their communities.

(See the section called “Number and Nature of Users”)

11.7.7.

What is the single biggest factor affecting the implementation of interactions?

 

For most organizing systems other than personal ones, the set of interactions that are implemented in an organizing system is strongly determined by economic factors.

(See the section called “Requirements for Interactions”)

11.7.8.

What is the most essential requirement of interactions?

 

An essential requirement in every organizing system is ensuring that the supported interactions can be discovered and invoked by their intended users.

(See the section called “Requirements for Interactions”)

11.7.9.

What is the role of computational agents in the creation and consumption of resource descriptions?

 

Automated and computerized processes can create the resource descriptions in an organizing system and their use is primarily driven by scale.

(See the section called “About the Nature and Extent of Resource Description”)

11.7.10.

What is the relationship between organizing principles and resource descriptions?

 

Organizing principles depend on resource descriptions, so requirements for the former are always intertwined with those for the latter.

(See the section called “About Intentional Arrangement”)

11.7.11.

What characteristics of resource descriptions impede growth?

 

Overly customized and inflexible resource descriptions or arrangements cannot easily accommodate the future growth of the collection.

(See the section called “Designing and Implementing an Organizing System”)

11.7.12.

What are the advantages of architectural thinking?

 

Architectural thinking leads to more modularity and abstraction in design, making it easier to change an implementation to satisfy new requirements or to take advantage of new technologies or procedures.

(See the section called “Architectural Thinking”)

11.7.13.

What is big data?

 

For digital resources, inexpensive storage and high bandwidth have largely eliminated capacity as a constraint for organizing systems, with an exception for big data, which is defined as a collection of data that is too big to be managed by typical database software and hardware architectures.

(See the section called “Architectural Thinking”)

11.7.14.

What are the most predictable maintenance activities?

 

The most predictable maintenance activities for an organizing system with an expected long lifetime are incremental changes in description vocabularies and classification schemes.

Another very predictable type of activity over time with organizing systems is a technology upgrade that improves its quality or capabilities without affecting the organizing principles.

(See the section called “Properties, Principles and Technology Perspective”)

11.7.15.

What changes in organizing systems make maintenance especially difficult?

 

The most challenging kinds of maintenance activities for organizing systems involve changes to the principles for arranging resources along with changes in the implementing technology.

(See the section called “Properties, Principles and Technology Perspective”)

11.7.16.

What six questions should be asked when approaching any organizing system?

 

What resources are being organized? Why are the resources being organized? Who does the organizing? When are the resources organized? Where are the resources organized? How much are the resources organized?

(See the case studies presented in Chapter 12, Case Studies)

 


[623] For some kinds of resources with highly regular structure, the distinction between the resource and its description is a bit arbitrary. A transactional document like a payment contains at its core a specification of the amount paid, which we could consider the payment resource. Information about the payer, the payee, the reason for the payment, and other essential information might be viewed as descriptions of the payment resource. In a payment or financial management system, the entire document might be treated as the resource.

[624] The results of this analysis can be represented in a conceptual model or document /database schema that can guide the automated creation of the resource instances and their descriptions (the section called “Abstraction in Resource Description”). Furthermore, these models or schemas can also be used in “model-based” or “model-driven” architectures to generate much of the software that implements the functionality to store the instances and interchange them with other information systems; “imagine if the construction worker could take his blueprint, crank it through a machine, and have the foundation for the building simply appear.” Quote comes from [(Miller and Mukerji 2003)]. See also [(Kleppe, Warmer, and Bast 2003)].

[625] See [(Chen, Li, Liang, and Zhang 2010)], [(Pohs 2013)].

[626] See http://autos.ca.msn.com/editors-picks/the-worlds-biggest-car-collectors.

[627] Model-driven software generation can be simple—an XFORM specification that creates an input form on a web page. Or it can be complex—a detailed architectural specification in UML sufficient to generate a complete application.

[628] Compare www.cdc.gov/philc and www.webmd.com.

[629] Service design, architecture, and user interaction design are the primary disciplines that care about the influence of layout and spatial arrangement on user interaction behavior and satisfaction. One type of physical framework is the “Servicescape” [(Bitner 1992)], the man-made physical context in which services are delivered. For example, the arrangement of waiting lines in banks, supermarkets, and post offices or the use of centrally-visible “take a number” systems strongly influence the encounters in service systems [(Zhou and Soman 2003)]. Related concepts for describing the use of features and orienting mechanisms in “the built environment” come from the “Wayfinding” [(Arthur and Passini 1992)] literature in urban planning and architecture.

[630] An easy to remember framework for prioritizing requirements is MoSCoW, which classifies them as Must, Should, Could, and Won’t [(Desoky 2010)]. [(Winkler and Pilgrim 2010)] is a comprehensive review of academic research and best practices for requirements traceability.

[631] “Customer segments” or “customer models” are well-established constructs in product and service marketing and operations [(Batt 2000)] [(Zeithami, Rust, and Lemon 2001)]. They are key parts of strategies for acquiring customers, increasing market share, and retaining customers. Customer segments can be identified using numerous overlapping criteria, including demographic variables, product or behavior choices, and preferred interaction locations or channels. For example, an airline might segment its customers according to their age, gender, home airport, ticketing class, and travel frequency.

[632] Funding cuts for public libraries lead to reduced staffing, reduced hours, and reduced acquisitions and many of them serve populations facing economic challenges of their own. [(Johnson 2010)].

[633] Organizing systems differ in the extent they can initiate interactions or use information to make them unnecessary. In libraries the organizing systems are typically designed not to preserve user activity records longer than absolutely necessary; in commercial organizing systems, user activity records are the basis of business processes that create highly detailed user models (called “microsegments” or “microcategories”) that enable personalized product and service offerings See [(Taylor and Raden 2007)], [(Rosen 2012)].

[634] The Dublin Core was proposed in 1995 as a small vocabulary with 15 common elements that could be broadly applied. The emergence of many specialized derivatives of the Dublin Core since then illustrates the inherent tension between the simplicity of using a small set of common descriptive elements and the precision enabled by a large or more domain specific vocabulary.

[635] [(Register and McIlroy 2012)] http://themetadatahandbook.com/.

[636] For example, we have often used a home kitchen as a setting for organizing systems. Suppose the home kitchen is to be used as the set for a cooking show and the designers want to arrange cookbooks to make the background visually pleasing. The designers would like to search for cookbooks on the basis of size and spine color, but these descriptive elements would be of little value to other users.

[637] The category of special libraries includes law libraries, corporate libraries—both those that support the head office and the research organization—medical libraries, military libraries, museum libraries, prison libraries, and might even be stretched to include libraries of software components.

[638] Some people call this the “Wal-Mart approach” to standardization. A firm with dominant market power does not need to negotiate standards because it can impose whatever standards it chooses on its partners as a condition of doing business with them. When there are conflicting requirements, different relationships within the set of participants trying to reach agreement, and different extents to which they are subject to the authority behind the desired agreement, it is not surprising that approaches “that require perfect coordination and altruism are of no practical interest” [(Rosenthal et al. 2004, p 47)].

[639] Note that this definition does not include any specific size threshold, such as some number of terabytes (thousands of gigabytes). This allows the threshold size that makes a collection a big data one to increase as storage technology advances. It also recognizes that different industries or domains have different thresholds [(Manyika et al 2011)].

[640] The history of the collection and the legal battle are described in [(Anderson 2003)]. A documentary film with a conspiracy perspective is [(Argott 2009)]. See also BarnesFoundation.org.

[641] See [(Sandler 2006)], [(Freeman et al. 2005)].

[642] No classification scheme ever devised is as unstable as the ACM’s because new computing concepts, technologies, and application areas are constantly emerging. Even the society’s name seems outdated.

[643] For a formal computer science treatment of BPEL see [(Fu, Bultan, and Su 2004)]; for a commercial perspective see http://www.oracle.com/technetwork/middleware/bpel/overview/index.html.

[644] This means that the organizing systems used by business applications more often employ configuration management, version control, model-based code generation, and other computing techniques that robustly support the need for qualitative changes in the organizing systems.

[645] [(Barta 2009)].

License

The Discipline of Organizing Copyright © by Robert J. Glushko. All Rights Reserved.

Share This Book