Para aquellos de ustedes que no estén familiarizados con la arquitectura de la información, existen numerosas definiciones de la arquitectura de la información, pero mi preferida es la de Louis Rosenfeld y Peter Morville «Information Architecture for the World Wide Web» (más conocida en los círculos de AI como el «libro del oso polar» por su cubierta distintiva), donde dicen que un arquitecto de la información es alguien que:
Aclara la misión y la visión del sitio, equilibrando las necesidades de su organismo patrocinador y las necesidades de su público. Determina el contenido y las funcionalidades que contendrá el sitio. Especifica cómo encontrarán los usuarios la información en el sitio, definiendo sus sistemas de organización, de navegación, de etiquetado y de búsqueda. Describe cómo se adaptará el sitio al cambio y al crecimiento con el paso del tiempo.
Sustituya la palabra «sitio» por «documento» y tendrá una idea de aquello de lo que hablo: los mismos principios se aplican a la visión del DA (arquitecto de la documentación).

El DAT (documento de arquitectura técnica) es un documento realizado por un arquitecto técnico o un arquitecto de la documentación. Define y documenta todo lo que hay que hacer y poner en marcha para lograr la implantación de la arquitectura, con el fin de alcanzar los objetivos y respetar las distintas restricciones.
Explica exactamente qué recursos técnicos (servidores, máquinas, redes, protocolos, etc.) son necesarios para responder a las necesidades y cómo deben implementarse dentro del SI, para mantener el rendimiento, la estabilidad, la seguridad, etc.
Existen varios formatos de DAT, que van desde unas pocas páginas con esquemas hasta informes completos y formales de más de 100 páginas. Hay que saber, sin embargo, que se trata de un documento vivo, concebido para ser consultado, comentado, evaluado y validado por las distintas partes interesadas.
Mi recomendación para abordar una arquitectura es dividirla en subconjuntos coherentes y complementarios. Es el enfoque clásico del ingeniero: se divide un conjunto complejo en partes más sencillas y manejables.
Por defecto, un sistema de información visto desde el ángulo de la arquitectura técnica puede descomponerse en 4 planos:
- El plano funcional, representa el aspecto de negocio, es decir, lo que hace la aplicación y la naturaleza de los datos que intercambia con el resto del mundo;
- El plano aplicativo se concentra en el aspecto de software: los flujos (protocolo, frecuencia, sentido), los almacenes (compartición de datos...), los middlewares (base de datos, servidor java...) y los frameworks utilizados (.NET, Java...);
- El plano de infraestructura permite describir las opciones técnicas: los servidores (en la nube o en otro lugar), su dimensionamiento, la interconexión a través de las redes, etc.;
- La capa operativa, por último, describe cómo se va a gestionar el sistema: los mecanismos de copia de seguridad, de supervisión, de metrología, etc.
Existen así 4 tipos de arquitectura en cada sistema.
- La arquitectura operativa
- La arquitectura funcional
- La arquitectura aplicativa
- La arquitectura técnica
«Arquitectura de documentación» no es (todavía) un término corriente: una búsqueda en Google hace aparecer páginas relativas a la manera de documentar la arquitectura de software. Lo que quiero decir con ello es que la manera en que los principios de arquitectura de la información que se han aplicado a la Web pueden utilizarse también para mejorar conjuntos de documentación, teniendo presentes las diferencias entre la Web y los numerosos tipos y formatos que adopta la documentación.
El DA debe adoptar un enfoque holístico para abordar la documentación: un tipo de documento es generalmente uno de los distintos tipos, cada uno con su propio objetivo y su público diferente. El tipo de persona que leerá una guía de «inicio rápido» es diferente del que va a sentarse a leer un manual de usuario, y usted debe tenerlo en cuenta al rediseñar estos tipos de documentos. Aunque tenga públicos diferentes para distintos tipos de documentos, el DA debe examinar y auditar todos los diferentes tipos de documentos disponibles para asegurarse de que todos tienen un sentido común del objetivo y de que contienen el tipo de contenido adecuado para su destino.
En lo que respecta a la funcionalidad, el DA debe considerar la manera óptima de organizarlo todo, desde los niveles de subtítulos que hay que utilizar en un índice hasta el orden para una indexación eficaz desde el punto de vista del usuario. Según el tipo de «documento», esto puede extenderse también a todos los elementos interactivos que entran cada vez más en juego (desde los cuestionarios interactivos, las encuestas, el vídeo integrado y las visualizaciones 3D). El DA garantiza asimismo que las etiquetas (piense en: encabezados o metadatos) son claras desde el punto de vista del usuario. La claridad prevalece siempre sobre el bombo publicitario y, en la medida de lo posible, concéntrese más bien en lo que el producto hace realmente y en cómo lo hace.
Por último, el DA debe reflexionar también sobre el ciclo de vida de un documento, no solo en lo que respecta a un producto determinado, sino también sobre la manera en que el propio documento puede evolucionar con el tiempo. Por ejemplo, hace una docena de años quizá era suficiente proporcionar un archivo de ayuda compilado para acompañar a un software, pero ahora existen todo tipo de otras opciones disponibles, incluida la ayuda web, la ayuda basada en un navegador local, los tutoriales multimedia integrados, etc. También hay momentos en los que un tipo de documento ya no es necesario, bien porque el producto al que está vinculado desaparece, bien porque ha sido sustituido por otro conjunto de documentos.
En resumen, el arquitecto de documentación es un arquitecto de información que se concentra en publicaciones, optimizándolas para su uso por parte de los lectores mediante la aplicación de los principios de la arquitectura de la información. Las empresas lo necesitan porque puede ayudar a hacer desaparecer el «dolor» asociado a un conjunto de documentación existente, puede ayudar a optimizar la transferencia de información a un sistema de gestión de contenidos (CMS) y también a lograr ahorros de productividad gracias a la reutilización del contenido. Si dispone de un conjunto de documentación de tamaño medio a grande y no dispone de un DA que lo gestione, sus publicaciones costarán inevitablemente más de lo necesario.
Como complemento encontrará a continuación un curso de Openclassrooms bajo licencia
CC BYSA 4.0.
¡Hasta muy pronto!
El artículo original llevaba documentos adjuntos («exemple_DAT.doc», «Comprenez les objectifs et attendus d'un DAT - OpenClassrooms.pdf»): el widget de descarga del antiguo editor no los trasladó al archivo, y no se vuelven a publicar.
