11.5: Diseño e Implementación de un Sistema de Organización

Los requisitos definen lo que se debe hacer pero NO cómo hacerlo; ese es el papel de las fases de diseño e implementación. Ser explícito sobre los requisitos y el alcance y la escala previstos de un sistema de organización antes de pasar a estas fases en el ciclo de vida de un sistema de organización evita dos problemas. El primero es tomar un enfoque estrecho y a corto plazo en los recursos iniciales de una colección, que podría no ser representativa de la colección cuando alcanza su alcance y escala planeados. Esto puede resultar en descripciones o arreglos de recursos demasiado personalizados e inflexibles que no pueden adaptarse fácilmente al crecimiento futuro de la colección. Un segundo problema, a menudo corolario del primero, es no separar los principios de diseño de su implementación en algún entorno o tecnología específicos.

Elección de la tecnología apropiada para el alcance y la escala

Un sistema de organización simple para satisfacer el mantenimiento de registros personales o algunos requisitos de administración de información de corta duración se puede implementar usando carpetas y archivos en una computadora personal o usando software genérico “listo para usar” como formularios web, hojas de cálculo, bases de datos y wikis. Otros sistemas de organización simples se ejecutan como aplicaciones en teléfonos inteligentes. Podría estar involucrada una pequeña cantidad de configuración, scripting, estructuración o programación, pero en muchos casos este trabajo se puede hacer de manera ad hoc. El bajo costo inicial para comenzar con este tipo de aplicaciones debe sopesarse frente al posible costo de tener que rehacer mucho del trabajo más tarde porque los recursos y las descripciones de los recursos podrían no ser fácilmente exportados a otros nuevos.

Los sistemas de organización más capaces que permiten el almacenamiento persistente y la recuperación eficiente de grandes cantidades de recursos de información estructurada generalmente requieren esfuerzos adicionales de diseño e implementación. Los archivos planos de procesamiento de textos y las hojas de cálculo no son adecuados. En cambio, a menudo se deben desarrollar modelos de documentos XML y esquemas de bases de datos para garantizar un mayor control y validación del contenido de la información y sus descripciones. También se debe desarrollar software para la gestión de versiones y configuraciones, seguridad y control de acceso, consulta y transformación, y para otras funciones y servicios para implementar el sistema de organización.

La tecnología para organizar sistemas siempre evolucionará para habilitar nuevas capacidades. Por ejemplo, la computación en la nube y el almacenamiento están cambiando radicalmente la escala de los sistemas de organización y la accesibilidad de la información que contienen. Podría ser posible implementar estas capacidades y servicios a un sistema de organización de manera incremental con métodos informales de diseño e implementación. Si en el software se codifican modelos de información, lógica de procesamiento, reglas de negocio y otras restricciones sin trazabilidad explícita a los requisitos y decisiones de diseño, el sistema de organización será difícil de mantener si el contexto, alcance o requisitos cambian. Es por ello que en repetidas ocasiones hemos enfatizado la importancia del pensamiento arquitectónico sobre la organización de los sistemas, comenzando en “El concepto de “principio organizativo” donde propusimos que los principios organizativos deberían expresarse idealmente de una manera que no asumiera cómo serían implementados. (Ver también ““Arquitectura de la información” y sistemas de organización”, “Clasificación vs. arreglo físico” e “Introducción”)

Pensamiento Arquitectónico

Gran parte de los consejos sobre el diseño e implementación de un sistema de organización se pueden resumir como “pensamiento arquitectónico”, introducido en “El concepto de “principio organizador””. El propósito general del pensamiento arquitectónico es separar los problemas de diseño de los de implementación para hacer que un sistema sea más robusto y flexible. El pensamiento arquitectónico conduce a una mayor modularidad y abstracción en el diseño, facilitando el cambio de una implementación para satisfacer nuevos requisitos o aprovechar las nuevas tecnologías o procedimientos. También es importante pensar arquitectónicamente sobre el diseño de los vocabularios y esquemas para la descripción de los recursos y de los sistemas de clasificación para dejar espacio para la expansión para dar cabida a nuevos tipos de recursos (“Categorías de implementación” y “Principios para mantener la clasificación a lo largo del tiempo ”). Hacerlo es más fácil si las descripciones son lógica y físicamente distintas de los recursos que describen. Una lista de verificación que reúne principios y procesos útiles para el pensamiento arquitectónico de todas las partes de este libro se encuentra en la barra lateral cercana.

Principios y Procesos

para Pensamiento Arquitectónico

• Definir explícitamente los fines y usuarios del sistema organizador, reconociendo que los usuarios podrían no ponerse de acuerdo sobre los propósitos o sus prioridades (“¿Por qué está siendo organizado?”) .

• Seleccionar recursos (“Criterios de Selección”) e interacciones de diseño (“Interacción y Creación de Valor”) para apoyar a los usuarios primarios o de mayor prioridad.

• Especificar los requisitos de información e interacción de una manera conceptual y tecnológicamente neutra (“El concepto de “principio organizador”) que se ajuste lo más posible a los estándares de dominio, esquemas o vocabularios (“Clasificación y Normalización”).

• Implementar interacciones de usuario con patrones de diseño para hacerlos más reconocibles, utilizables y efectivos (“Arquitectura de la Información” y Sistemas Organizadores”).

• Siga los principios para los buenos nombres (“Elegir buenos nombres e identificadores”) y buenas descripciones de recursos (“Principios de buena descripción”).

• Tomar una decisión informada sobre el equilibrio entre flexibilidad y complejidad; un sistema más simple podría ser más fácil de adaptar (“Principios para mantener la clasificación a lo largo del tiempo”).

• Tomar decisiones de diseño y tecnología consistentes con la vida esperada del sistema organizador (“Operando y Manteniendo un Sistema Organizador”).

Detente y Piensa: ¿Qué es una Biblioteca?

La palabra “biblioteca” tiene varios significados que difieren en cuanto pensamiento arquitectónico encarnan. Cuando le dices a alguien te encontrarás con él en la biblioteca para tomar una taza de café y una sesión de estudio es un lugar físico específico. En otras ocasiones, podría usar una noción más abstracta de una biblioteca como un sistema de organización con un tipo predecible de colección, disposición de recursos e interacciones soportadas. Ambos significados son importantes para una ciudad que crea una nueva biblioteca. ¿Cómo te asegurarías de que ambos sean considerados de manera efectiva?

Sin embargo, el pensamiento arquitectónico requiere un análisis más cuidadoso de los recursos y alternativas de implementación, y la mayoría de la gente no piensa de esta manera, especialmente para los sistemas de organización personal e informal. Te imaginas que alguien podría organizar una colección de libros de bolsillo en una pequeña estantería cuya altura y ancho de estante eran perfectamente adecuados para los libros de bolsillo que actualmente poseen. Sin embargo, este sistema de organización no funcionaría en absoluto para libros de gran formato, y no se podría agregar un libro de bolsillo a la colección a menos que uno fuera purgado de la colección. Sería más sensato comenzar con una librería más grande con estantes ajustables para que el sistema de organización tuviera una vida útil más larga.

Se podría pensar que los grandes sistemas de organización institucional evitarían estos problemas causados por atar una colección demasiado apretada al entorno físico en el que se organiza inicialmente, pero a veces no lo hacen. Un ejemplo famoso involucra la colección de arte de la Fundación Barnes, que tuvo que mantener sus pinturas exactamente en los mismos arreglos abarrotados cuando el museo hizo un polémico paso de un edificio pequeño a uno más grande porque el donante había ordenado que las pinturas nunca se movieran de su original ajustes. (Ver la barra lateral, La colección Barnes).

Para los recursos digitales, el almacenamiento económico y el alto ancho de banda han eliminado en gran medida la capacidad como restricción para organizar sistemas, con una excepción para big data, que se define como una recopilación de datos que es demasiado grande para ser administrada por software y hardware típicos de bases de datos arquitecturas. ^[1] Aun así, las colecciones de big data suelen ser grandes pero homogéneas, por lo que su escala no es su reto más importante desde la perspectiva del sistema de organización (“Alcance y Escala de la Colección”).

La colección Barnes

Albert Barnes fue un químico que hizo fortuna inventando un tratamiento preventivo para la gonorrea y que luego acumuló quizás la mayor colección de arte privada de la historia, una que contenía más de 800 pinturas de artistas como Picasso, Renoir, Matisse, van Gogh y Cézanne. En 1922 Barnes construyó un museo para su colección en su barrio residencial en Merion, PA, un suburbio de Filadelfia. Barnes no abrió su colección al público y en su testamento ordenó que la colección nunca se moviera, se prestara ni se vendiera.

En las décadas posteriores a la muerte de Barnes en 1951, el museo Merion necesitaba reparaciones extensas y mejoras de seguridad, y algunas personas sugirieron que su ubicación remota y las restricciones de acceso ponían en peligro su viabilidad financiera. No obstante, una propuesta de reubicar la colección a Filadelfia aparentemente violó los términos del testamento de Barnes.

Una pelea legal se prolongó durante décadas. Por último, en 2004 un juez dictaminó que la colección podría trasladarse a Filadelfia, pero sólo si el nuevo museo contenía copias exactas de las salas de la galería del museo original y dispuso las pinturas exactamente como estaban en Merión. El nuevo edificio del museo, inaugurado en 2012, es diez veces más grande que el antiguo, pero la colección ocupa el mismo espacio que en Merión. El otro 90% del edificio está ocupado por un auditorio, oficinas, aulas, una tienda de regalos y otro espacio que no contiene nada de la colección. ^[2]

Distinguir el acceso del control

Debido a que las grandes colecciones de recursos a menudo son utilizadas para múltiples propósitos por muchas personas o proyectos diferentes, ilustran otro problema arquitectónico importante para las colecciones de recursos digitales. Un requisito para el acceso a los recursos no implica la necesidad de poseerlos o controlarlos directamente, y las empresas con uso intensivo de información y basadas en la web han adoptado cada vez más diseños de sistemas de organización que involucran el almacenamiento de recursos digitales en la nube, la concesión de licencias de recursos distribuidos globalmente y externalización de servicios de información. Los diseños que utilizan estos conceptos arquitectónicos pueden realizar mejoras funcionales y de calidad porque la ubicación e identidad del proveedor de servicios está oculta por una capa de abstracción (“Creación de Valor con Recursos Físicos”, “Distinguir Identificar y Resolver”). Sin embargo, separar el acceso de la propiedad ha sido un reto cultural para algunas bibliotecas y museos cuyas identidades institucionales enfatizan los recursos que controlan directamente y los edificios físicos en los que los controlan. ^[3]

Normalización y Consideraciones Legadas

Como señalamos con la Colección Barnes, un edificio se vuelve viejo y anticuado con el tiempo. La tecnología utilizada en los sistemas de organización digital se vuelve obsoleta más rápido que los edificios físicos. La mejor manera de frenar la inevitable transformación de la tecnología de vanguardia actual a la tecnología heredada del mañana es diseñar con formatos de datos estándar, vocabularios y esquemas de descripción, y sistemas de clasificación, a menos que tenga requisitos específicos que excluyan estas opciones.

Incluso un requisito para interoperar con un sistema de organización que utilice especificaciones propietarias o no estándar generalmente puede satisfacerse transformándose de un formato estándar (“Semántica Institucional”, “Implementación de Interacciones”). De igual manera, es mejor diseñar las API y los feeds de datos de un sistema de organización de manera genérica o estándar que abstrae de su implementación oculta. Este principio de diseño facilita a los usuarios externos la comprensión de las interacciones soportadas, y también evita la divulgación de cualquier aspecto de la descripción de los recursos u organización que proporcione una ventaja competitiva. Por ejemplo, la manera en que un negocio clasifica productos, proveedores, clientes o empleados puede ser competitivamente importante.

Dos cuestiones importantes de diseño que surgen con la transformación o conversión de datos, ya sea que sea requerida por una actualización tecnológica o un requisito de interoperabilidad, son cuándo hacerlo y dónde hacerlo. El trabajo de convertir todos los recursos en una colección generalmente se puede subcontratar a una empresa que se especializa en la conversión de formato o descripción de recursos, y una conversión por lotes o preventiva de una colección completa permite que un sistema de organización actualizado o nuevo funcione de manera más eficiente cuando no lo es distraído por la actividad de conversión en curso. Por otro lado, si los recursos varían mucho en su frecuencia de uso, un método de “hágalo usted mismo bajo demanda” probablemente sea más rentable siempre y cuando la conversión no impacte en las interacciones que necesitan ser soportadas.

---

1. Tenga en cuenta que esta definición no incluye ningún umbral de tamaño específico, como algún número de terabytes (miles de gigabytes). Esto permite que el tamaño del umbral que hace que una colección sea una de big data aumente a medida que avanza la tecnología de almacenamiento. También reconoce que diferentes industrias o dominios tienen diferentes umbrales (Manyika et al 2011).

   
   

2. La historia de la colección y la batalla legal se describen en (Anderson 2003). Un documental con perspectiva de conspiración es (Argott 2009). Ver también BarnesFoundation.org.

   
   

3. Ver (Sandler 2006), (Freeman et al. 2005).