La escalabilidad en las Arquitecturas de la Web 2.

Museo Guggenheim de Bilbao.

Las tres Arquitecturas de la Web 2.0

Una obra maestra que muestra como la Arquitectura subyace en la funcionalidad y la estética
de las grandes obras. Hemos hablado varias veces de la Web 2.0, esa capacidad de la Internet
de hoy que permite el desarrollo de plataformas que se mueven con información y
comunicaciones, donde resalta la presencia de una alta interactividad y una gran participación,
técnicamente basadas en los protocolos de la World Wide Web.

En ellas los contenidos y el valor se crean en gran medida por la participación de los usuarios y
todo lo que se hace está en constante evolución, sin que haya nunca, por definición, un
producto completamente acabado, sino que, por el contrario, todo se considera en lo que se
ha venido denominando un beta perpetuo.

Una pregunta sin duda interesante es cómo es que se construyen estos sitios Web 2.0, con la
intensa interactividad que los caracteriza. La respuesta es que lo hacen con Arquitectura. Al
igual que con las obras físicas, donde es fácil reconocer que nada grande, estético y funcional,
se construye sin ellas, estas creaciones del mundo digital logran desarrollarse como entes vivos
en la Internet gracias a que se realizan con el desarrollo de arquitecturas fundamentales.

Hay tres Arquitecturas involucradas en todos estos sitios Web y un observador entrenado las
puede distinguir claramente. Ellas trabajan mancomunadamente y complementariamente para
lograr el resultado final. Las tres arquitecturas a las que nos referimos son la Arquitectura de
participación, la Arquitectura de Información y la Arquitectura tecnológica.

La Arquitectura de Participación es la que diseña los espacios de interacción donde ocurren los
procesos de información y comunicación visibles. El trabajo dentro de ella implica el desarrollo
de Comunidades, la conversación de nuevos Medios sociales, la claridad en las Motivaciones
para participar que se proponen, la Viralidad en las propuestas de valor y en los contenidos.
La Arquitectura de Información es la que se ocupa del diseño del manejo de la información.
Ocurre en un espacio un poco más interno donde se caracterizan los Tipos de contenidos, se
construyen Modelos de Información, Esquemas de Navegación y se definen como deben usarse
Taxonomías y Folksonomías para lograr clasificar la información adecuadamente, facilitando su
manejo tanto a los usuarios finales como a los responsables de los servicios.

La Arquitectura tecnológica es en algún momento muy visible en los equipos de computación

y comunicaciones que sirven de soporte al software y los sistemas, sin embargo, hoy día es cada
vez más invisible en la llamada Computación de nube, donde sabemos que en algún lugar
residen máquinas altamente conectadas que almacenan, procesan, reciben y entregan la
información, pero donde no sabemos ni nos ocupamos en saber dónde están.

Existe la tendencia a usar los servicios profesionales de hospedaje que aportan infraestructuras
sofisticadas, de hardware y software, donde siempre hay que garantizar una alta Disponibilidad
y Escalabilidad de los servidores y donde las variables como la seguridad se resuelven con
prácticas de ingeniería muy evolucionadas. Necesitamos tener idea de los dominios de las
decisiones involucrados en estas tres arquitecturas para entender cómo construir un sitio Web
2,0.

El mérito no viene de los computadores: ¿Cómo describimos nuestras operaciones en un

archivo digital? Muchas veces se diseñan archivos digitales bajo la cultura del papel; La
diferencia en eficiencia aparece, sin embargo, cuando se usan criterios de Arquitectura de
Información.

Los resultados eficientes en las buenas soluciones de gestión institucional no se obtienen desde
el mero uso de computadores y herramientas tecnológicas, estos, por supuesto, hay que
usarlos, pero lo que verdaderamente hace la diferencia es la organización de la información con
criterios de Arquitectura de Información y para ello distinguimos cuáles son los objetos de
información que están en nuestros procesos y creamos modelos que representan estos
procesos. Luego aplicamos estos modelos, ojalá alimentado herramientas que nos permitan
implementar las soluciones con prototipos generados automáticamente, sin tener que
desarrollar software, sino solamente configurar alguna plataforma con nuestros modelos.

Este es el camino eficiente y seguro para crear archivos digitales. En este marco, para
estructurar la información debemos preguntarnos: ¿Cómo describimos nuestras operaciones
institucionales al crear un archivo digital? A pesar de que evidentemente no hay una receta
universal para hacerlo, si hay métodos y procesos que se repiten, incluso, cuando se trata de
soluciones que debemos construir para casos muy diferentes. En general, debemos hacer una
lista de las propiedades que tienen nuestras operaciones. Por ejemplo, es común que haya un
Tipo de operación que se define según como las clasifiquemos. Por ejemplo, activas y pasivas,
internas y externas, etc. Puede haber Subtipos de operaciones, si hay clasificaciones
secundarias dentro de los grupos principales. Una propiedad importante es la identificación de
la operación. Normalmente un número o código que la identifica en forma única. Puede haber
varias fechas, típicamente hay una fecha de inicio, una fecha de finalización y a veces algunas
otras.
Suele haber criterios de clasificación y estados, o valores que determinan como está esa
operación respecto a ciertos criterios. Por ejemplo: aprobada, reprobada, en evaluación.
Algunas veces puede haber criterios administrativos que indican los pasos en los que se
encuentra el trámite.

La operación normalmente tiene que ver con personas, internas y externas. Por ejemplo, en un
trámite de registro civil de una persona están los padres, el hijo, los testigos, el registrador, el
secretario, etc. En una operación de compra-venta está el vendedor y el comprador. En una
operación bancaria están los titulares, los accionistas, los fiadores, los representantes
legales. La operación también puede tener que ver con documentos y de allí se derivan las
relaciones o asociaciones de la operación con los documentos.

Lo interesante en que con Arquitectura de Información muchas de las propiedades son

relaciones digitales que pueden estar vacías (por ejemplo, puede o no haber fiador) o que deben
estar llenas porque son obligatorias según las reglas institucionales (por ejemplo, siempre debe
haber un titular). Bajo la cultura del papel las relaciones no funcionan bien, porque si guardamos
los datos del objeto de información relacionado en la misma carpeta de la operación tendemos
a duplicar la información, a general redundancias e inconsistencias y si las guardamos afuera el
tener el expediente completo de una operación que involucra múltiples personas y documentos
tiende a ser muy complicado de reunir.

Debido a las limitaciones señaladas, es común que en una organización de la información

realizada con la cultura del papel (usando o no computadores) se pierda el control de las
vigencias de algunas relaciones. Debida a ello, por ejemplo, son muchos los bancos que pasan
trabajo ante las auditorías públicas, porque, aunque usan tecnologías de la información,
muchos de sus procesos de archivos están basados en la cultura del papel.

¿Qué debería ser el expediente digital de un cliente?

La diferencia entre un archivo organizado digitalmente y uno organizado en papel debería ser
mucho más que el medio físico de almacenamiento.

Hay distinciones de Arquitectura de Información involucradas, veamos cuando hay Arquitectura

de Información el expediente digital de un cliente es algo diferente de un conjunto de hojas en
una carpeta almacenada en un archivador para documentos impresos en papel. La diferencia
no está en el medio que soporta la información. Algunas organizaciones usan computadores y
por tanto almacenan información en medios electrónicos, pero organizan la información sin
Arquitectura, como si los procedimientos que se usaban bajo la cultura del papel fueran
apropiados conceptualmente, cuando la verdad es que estos procedimientos tienen un origen
histórico, pero no son los adecuados. El expediente digital de una persona debería ser algo
diferente a lo que era en el pasado y cuando se hacen bien los Archivos Únicos Digitales de
Clientes deben ser muy eficientes. Analicemos a continuación la naturaleza de estas diferencias.

Los objetos de información que básicamente se manejan en un archivo de clientes son las
Personas, las Operaciones, los Documentos físicos y las Reglas de Negocios institucionales.
Lo propio es que cada uno de estos objetos de información tenga asociaciones hacia los otros,
realizadas a través de los procesos u operaciones que los vincularon. Así, por ejemplo, si
partimos de una persona podemos saber cuáles son las operaciones que ha realizado, bajo que
reglas institucionales las hizo y cuáles son los documentos físicos que las soportan.

Si partimos de una lista de operaciones y seleccionamos una, podemos saber también cuáles
son las personas que intervinieron, bajo que reglas de negocio y con qué documentos de
respaldo. Si el punto de partida es un documento de, por ejemplo, una lista de documentos
vencidos o próximos a vencer, podemos saber cuáles son las operaciones y clientes afectados
por ese vencimiento. También si se tratase de una institución que tiene su archivo físico
distribuido en distintas ciudades, podríamos saber en cuál de las posibles locaciones se
encuentra archivado el documento original.

Esto es muy diferente a lo que se hacía bajo la cultura del papel. Ésta obligaba a obligaba a
establecer las relaciones entre clientes, operaciones, reglas institucionales y en expedientes
físicos a través de carpetas que por las limitaciones del medio sólo podían tener un criterio de
ordenamiento y, en el mejor de los casos, se usaban fichas o listados para resolver la diversidad
de criterios de búsqueda.

¿Cuál es el problema? ¿Cuál es la diferencia? ¿Cuál es el aporte de la Arquitectura de

Información?

El hecho que en las soluciones pensadas para medios digitales las asociaciones entre instancias
son naturales y prácticamente inmediatas, no hay límites en la cantidad de asociaciones entre
instancias que se pueden tener y esto hace que buscar y recuperar la información relacionada
sea sencillo conceptualmente hablando.

Veámoslo en un caso muy concreto para entenderlo mejor: Bajo la antigua cultura del papel la
información de un fiador de un crédito bancario, por ejemplo, estaba almacenada en la carpeta
del crédito. Si ese fiador era además un cliente que realizaba sus propias operaciones, o era
fiador de otra persona, o accionista de una empresa, la información estaba duplicada en otras
carpetas. Si el archivo se digitalizó sin Arquitectura de Información es probable que se
mantengan las mismas ineficiencias y duplicados, mientras que, con una Arquitectura de
información adecuada, la información de una persona está almacenada una única vez y es
recuperable desde cualquier esquema de búsqueda que se haya realizado.

Por esto los Archivos Únicos Digitales son más sencillos conceptualmente, más económicos de
espacio, más simples de operación y producen relaciones más adecuadas con los clientes ya
que a nadie se le pide que vuelva a soportar con nuevos documentos lo que ya es soportado
por los documentos presentes en el archivo institucional.

Expedientes físicos y diseño de un Archivo Digital sin la cultura del papel

En un archivo digital diseñado y construido con criterios de Arquitectura de Información la

respuesta institucional es eficiente porque los sistemas manejan todas las relaciones
digitalmente, sin duplicar ni los documentos físicos ni los documentos digitales, sin necesidad
de fotocopias, ni valijas y administrando siempre la vigencia de cada documento.

Como un ejemplo de lo que se puede hacer con Arquitectura de información hemos estado
hablando en las últimas semanas del concepto de Archivo Único Digital de Clientes y sus
diferencias con las aproximaciones tradicionales, que, aunque usan instrumentos de las
modernas tecnologías de la información (computadores de última generación, bases de datos,
software, redes, etc.) están aun fuertemente influenciadas por la cultura de la organización de
documentos de papel. Distinguimos recientemente que no es lo mismo organizar la información
que organizar documentos, que, si bien lo segundo es necesario, sólo se puede hacer bien
cuando se enmarca y se resuelve en una organización estructurada con criterios de Arquitectura
de información (AI). Con esto en mente conversaremos hoy sobre el manejo de los expedientes
físicos cuando se construye un Archivo Único Digital de Clientes.

Hemos visto (¿Por qué la misma institución te pide varias veces los mismos documentos?) que
cuando no hay AI los trámites institucionales se tornan engorrosos para el cliente, el obtener la
información en forma adecuada un problema complicado para la institución y que a pesar de
las herramientas digitales en ocasiones se le pide al cliente documentos que la institución ya
dispone en sus archivos físicos. ¿Cuál es la estructura de información que se debe manejar para
que esto no ocurra?

Los objetos de información básicos que se deben usar en un Archivo digital de expedientes de
clientes (Ver ¿Qué es un Archivo Único Digital de Clientes? Parte 1 y Parte 2) son cuatro: los
clientes, los expedientes físicos, las operaciones y las reglas dinámicas de negocio. Con una
Arquitectura de información adecuada se combinan estos objetos de información para
construir archivos digitales que tienen como característica principal el hecho de permitir una
gestión de las operaciones basadas en información y relaciones digitales más que en
documentos y cultura de papel, fotocopias y carpetas.

Los documentos físicos se digitalizan y se hacen disponibles cuando se le necesitan, asociados

digitalmente a los clientes y a las operaciones y por tanto no duplicados en carpetas. Para el
usuario institucional los documentos están siempre disponibles y siempre asociados a las
operaciones pertinentes. Así, por ejemplo, si dos personas son clientes de una institución y sus
documentos respectivos por tanto ya se registraron previamente y están vigentes, cuando en
una nueva operación estos se involucran, el sistema incorpora automáticamente, en forma de
asociación digital, sus respectivos documentos, conforme a las definiciones de las reglas de
negocios definidas. Si el documento existe en el archivo, pero está caduco, el sistema lo
advierte. Por tanto, nunca se le pide a ningún cliente, innecesariamente, que vuelva a entregar
una copia o un original de lo que está aún vigente.

El objeto de información de expedientes físicos hace posible la administración física de los

documentos en papel y la asociación digital en todos los trámites que le requieren. Cuando
algún documento caduca, el sistema advierte directamente al cliente que debe entregar una
versión actualizada del mismo. De esta manera y haciendo las alertas necesarias el sistema se
ocupa de la actualización para que los documentos almacenados se mantengan vigentes. Se
garantiza también que no haya documentos duplicados en los archivos y se eliminan las
solicitudes innecesarias de documentos a los clientes cuando estos realizan transacciones.

Cuando el cliente entrega la nueva versión de un documento se actualiza el archivo físico y el

archivo digital, consecuentemente, en virtud de las asociaciones digitales correspondientes los
expedientes digitales quedan actualizados instantáneamente, sin que se duplique ni la
información física ni la información digital. Para las personas que tienen que manejar el archivo
o los archivos físicos, es fácil ubicar y sustituir el documento. Los que tienen que manejar la
información no se ocupan para nada de los documentos físicos, sino que siempre recuperan
información digital pertinente.

¿Qué es un Archivo Único Digital de Clientes?

No es lo mismo administrar información que administrar documentos: Un Archivo Único Digital

de Clientes es una solución moderna, disruptiva respecto a las soluciones tradicionales que
heredan conceptos de la cultura del papel.

Como en muchos sitios hay empresas que manejan las herramientas de las nuevas tecnologías
de la información, pero permanecen inmersos en la cultura del papel. A esta cultura le debemos
los archivos en carpetas donde, lamentablemente, tenían que duplicarse numerosas veces los
documentos, generándose muchas copias de la misma información, se ocupaba mucho espacio
físico y se hacía un tipo de procesamiento que terminaba siendo una carga costosa y que, como
agravante, generaba situaciones bochornosas, como por ejemplo, pedirle a un cliente los datos
de un fiador, aunque toda la información de ese fiador estuviera ya en tu archivo porque se
trata de un cliente regular de tu institución. Esto aún ocurre en bancos, compañías de seguros,
empresas, organizaciones de servicios de todos los tipos y entes gubernamentales. La solución
al caso, señalamos, era un Archivo Único Digital de Clientes. ¿Qué es esto y cómo se construye?

Un punto de partida importante es darse cuenta que el desarrollo de un Archivo Único Digital
de Clientes no es un tema de software, de bases de datos, de informática o de tecnología.
Pensar eso es distraerse. Si se quiere una solución efectiva se debe reconocer desde el inicio
que se trata de un tema de Arquitectura de Información. En efecto, lo crítico en un proyecto de
esta naturaleza es el desarrollo de un modelo de gestión que integralmente de cuenta de los
procesos que realizamos en las distintas operaciones que hacemos con nuestros clientes y,
particularmente, que se adapte naturalmente a los flujos de información implicados en nuestras
transacciones. Para hacer ello hay que partir de la taxonomía con la que clasificamos todos
nuestros servicios, revisar los documentos que requerimos como recaudos y, por supuesto, la
información y los documentos que, consecuentemente, producimos en cada tipo de
transacción que realizamos.

Un banco, por ejemplo, realiza operaciones activas y pasivas. En cada una de ellas tiene distintos
tipos de productos. Su departamento de créditos ofrece y otorga créditos para empresas y otros
tipos de personas jurídicas y créditos para personas naturales. Para cada una de ellas hay una
gama de productos. Para personas naturales, por ejemplo, hay créditos hipotecarios para la
adquisición de viviendas, créditos para remodelaciones, créditos para la adquisición de
vehículos, etc. Las personas naturales y las jurídicas tienen sus documentos descriptivos
característicos y los productos también tienen su lista de recaudos específicos. Los recaudos
son documentos y los documentos tienen períodos de vigencias, ya que siempre tienen
asociadas fechas de emisión y de caducidad.

Algunos de estos recaudos se solapan, de un modo natural, en la descripción de cada tipo de

operación. Pero esto no significa que deban solicitarse múltiples veces la información que ya
está vigente en el archivo. Un sistema digital, realmente inteligente, debe darse cuente que, si
una segunda transacción se realiza con un mismo cliente, seguramente los soportes ya están,
total o parcialmente, en el archivo.

Conforme a lo dicho, en un Archivo Único Digital de Clientes los dos calificativos de su nombre
son importantes. Es primero que nada un Archivo Digital, para nada parecido a un archivo físico.
El concepto está totalmente desligado de la cultura de las fotocopias y el papel. La información
no se guarda en carpetas. Adicionalmente es también Único, la información no se duplica, no
se requiere un archivo en cada oficina para prestar el servicio, no se molesta al cliente
pidiéndoles varias veces lo mismo, no requiere del envío constante de valijas de una ciudad a
otra. De allí su eficiencia y economía.

¿Por qué la misma institución te pide varias veces los mismos documentos?

Cuando se maneja inadecuadamente la Arquitectura de Información en los procesos de gestión

de una institución se maltrata al cliente ¡volviendo a solicitarle documentos que ya ha
entregado!

En diferentes temas relacionados con la Arquitectura de información. Desde la definición misma

de la profesión, hasta los distintos procesos en los que trabajan los Arquitectos de Información
resolviendo los problemas que les son naturales. Hemos visto que una institución puede tener
una gran infraestructura informática y una gran cantidad de personal en su departamento de
tecnología, pero si sus soluciones de gestión no han sido diseñadas con la intervención de
Arquitectos de Información, la implementación de sus procesos tendrá muchos inconvenientes,
tanto para la propia organización, como para sus clientes. Hoy queremos referirnos a un detalle
en el que como usuarios podemos darnos cuenta de las limitaciones de la Arquitectura de
Información de una institución: al hacer un nuevo trámite, ¡te solicitan de nuevo documentos
que ya te han pedido en transacciones anteriores!

El problema ocurre una y otra vez, incluso en compañías grandes, en organizaciones que
manejan mucho dinero, en organizaciones internacionales que no han incorporado aún la
esencia de los cambios con que se maneja la gestión de información en el siglo XXI: Solicitas un
nuevo crédito en un banco, abres una nueva cuenta, contratas una nueva póliza de seguro y la
institución te entrega una lista de recaudos que debes satisfacer. En la lista no se te eliminan
los documentos que entregaste al hacer trámites previos y que todavía están vigentes. ¡Incluso
pueden volver a solicitarte de nuevo una copia de tu documento de identidad!

Todo ello es un absurdo, si el banco o la compañía de seguros ya tiene copia de esos

documentos, ¿Por qué te los vuelve a pedir? La respuesta es digitalmente sencilla: es una
herencia de la cultura del papel. El nuevo trámite va a una carpeta física diferente, en un archivo
diferente, en un departamento diferente, aun pensando que se trate de la misma institución.
La institución descarga en el cliente su incompetencia en el diseño de procesos de información.
Puede que en el mismo departamento existan copias de los mismos documentos del mismo
cliente, ¡pero cada uno estará en una carpeta diferente! La vigencia no se toma en cuenta en
los nuevos trámites, no se integra la información digitalmente.

La manera de hacer bien las cosas es mantener un archivo único digital de clientes donde cada
operación tenga definidos sus recaudos necesarios y un sistema digital apropiado revise en tu
expediente cuáles documentos tú ya has introducido, se dé cuenta de las correspondientes
vigencias y gracias a ello se te comunique qué es lo único que debes entregar, pudiendo darse
el caso en que efectivamente no tengas que entregar nada, ya que todos los recaudos
necesarios los has entregado en oportunidades anteriores y están aún vigentes.

El definir procesos de esta naturaleza, con una máxima eficiencia tanto para la institución como
para el cliente, aprovechando al máximo las nuevas posibilidades que ofrecen las tecnologías
de la información pero también, el conocimiento de las ciencias de la información, es parte del
trabajo que hacen los Arquitectos de Información en el interior de las organizaciones, en los
departamentos adecuados, o a través de empresas especializadas en el diseño, desarrollo e
implementación de este tipo de procesos, como la gestión de un Archivo Único Digital de
Clientes. En su ausencia, las organizaciones hacen cosas extremadamente impropias de la
presente fecha, como, por ejemplo, volver a pedirle su documento de identidad o sus
referencias a un cliente con el que ya mantienen relaciones.

¿A quién le notificamos los cambios?

En un sistema moderno los usuarios son participados en forma permanente acerca de cada
cambio que ocurre en los asuntos que les conciernen. Pero hay detalles sofisticados en la
definición de estos procesos.

No cabe duda que los sistemas de información modernos son más sofisticados que los que
hacíamos en otras generaciones. Es natural. Ahora podemos hacer más y lo hacemos. Los
conocimientos y las tecnologías son más evolucionados. Esa sofisticación se traduce para el
usuario de aplicaciones modernas en que ahora, al menos en general, hacer las cosas debe
resultar más sencillo que antes. Pero la sofisticación también incluye la complejidad. Es un
hecho que ahora, en el rol de usuarios finales, podemos hacer cosas que antes no las
considerábamos porque eran complicadas. Si cambiamos ahora el punto de vista a las
perspectivas de los que construyen las aplicaciones, la sofisticación significa que hoy hay más
cosas para especificar. Debemos hacernos preguntas sobre temas de los que antes quizá ni
siquiera hablábamos. Es claro que alguna gente tiene ahora que preguntarse cuál es la mejor
manera de construir y mantener un robot en la superficie de marte y que antes, cuando esto
no existía como posibilidad, la pregunta no se hacía. Con esta introducción hoy queremos
profundizar a partir de una pregunta simple: ¿A quién le notificamos los cambios de estado que
ocurren en un sistema?

Lo primero en que debemos hacernos conscientes es que los sistemas de información

modernos notifican en forma sofisticada. Una premisa elemental es que todos los usuarios
tienen, al menos, una dirección de correo electrónico y que, a través de ella, debe ser
participado de los cambios que ocurren en la información de los sistemas y que tienen que ver
con ellos.

La experiencia de compra a través de la red, por ejemplo, nos muestra que al menos los cambios
básicos, que el sistema reconoce que hicimos una orden, que nuestra orden fue despachada y
que lo que ordenamos se considera entregado se nos informa por defecto en un sistema bien
comportado. A partir de allí podemos enterarnos de estados intermedios de nuestra orden, por
ejemplo, que lo que ordenamos está en tránsito entre un punto A y un punto B. Así funciona
un sistema moderno.

Notemos entonces de nuevo algunos aspectos de Arquitectura de información de los que

hemos hablado: la información está constituida por objetos de información (ver Estructuras de
información) y la dinámica de la información (ver Dinámicas de información) se traduce en que
estos objetos cambian de estados (ver Transiciones de estado). De lo que se trata entonces es
que un sistema moderno, sofisticado, debe informar acerca de las transiciones de estado a los
usuarios involucrados (ver Diseño de notificaciones...). Si ahora tomamos la perspectiva del que
diseña o del que construye una aplicación moderna debemos hacernos la pregunta de ¿A
quiénes notificamos?

La respuesta también es sofisticada y tiene sus aristas. Cada estado definido dentro de un
objeto de información de un sistema es un punto de llegada y un punto de partida. Los cambios
son transiciones. Esas transiciones tienen que estar asociadas a comunidades de usuarios y lo
normal (y el punto de partida por defecto) es informar en la ejecución de cada transición a todas
las comunidades de usuarios asociadas a ella. Pero hay dinámicas de construcción de procesos
dentro de estas dinámicas de producción (¡que sofisticación!): cuando estamos definiendo los
mensajes a quienes debemos notificar es a los usuarios que participan en esta tarea, cuando
creemos que los mensajes están listos debemos notificar a los validadores de los procesos, en
principio, personas diferentes. Y cuando ya el proceso está definido, los mensajes deben llegar
a las personas miembros de las comunidades involucradas en la transición misma (y no a los
constructores y validadores de procesos).

La observación interesante es que todo esto es Arquitectura de información. Algo que no es

software ni ingeniería sino diseño de procesos de información, de sistemas de información
sofisticados, de esos que ahora podemos hacer y que hacemos y que socialmente marcan
nuestra cotidianeidad de forma diferente. Los gerentes de información deben conocer la
necesidad de este trabajo de Arquitectura de información en la fase de diseño de cualquier
sistema moderno, independientemente de las herramientas de gestión de conocimiento, de
información, de documentos o de software con la que vayan luego a construir sus sistemas.

Identificación de la visión compartida en una propuesta de gestión de información

Una visión compartida entre desarrolladores y contrapartes no asegura el éxito, pero es

condición necesaria. El ciclo de vida de aplicaciones de gestión de información desarrolladas
con criterios de Arquitectura de Información, que en el camino desde su nacimiento hasta su
desaparición las aplicaciones recorren un ciclo que comienza con la identificación de
necesidades. Queremos detenernos un poco en esta etapa básica o inicial donde nos hacemos
la idea general de lo que queremos y le damos forma conceptual a lo que vamos a hacer,
nuestro plan de trabajo, bien sea éste de desarrollo de un nuevo servicio de información o de
mejora de uno existente. No revisaremos hoy cuáles son las actividades naturales en esta
etapa, ni cuáles son los resultados que debemos obtener o entregar. Antes bien queremos
apreciar algo más básico: Por qué momentos se pasa al identificar la solución y cuál es la
importancia que estos pasos tienen en el eventual éxito o fracaso del proceso.

Generalmente la identificación de la solución de gestión se logra en dos pasos característicos:

la definición del proyecto y la conceptualización de la solución. Pueden llamarse diferente en
la literatura, pero lo típico es que la transformación que se busca en cualquier iniciativa de
mejora en la gestión de información requiere que se formule como un proyecto, primero en
forma gruesa y luego con detalles. Pero no es tan simple como parece. Es importante darse
cuenta de qué es lo que la instancia que requiere el cambio normalmente tiene que acordar
con una tercera parte, bien sea ésta una empresa consultora o una unidad interna de una
corporación o institución. Siempre se requiere asegurar que ambas partes estén identificadas
en cuál es el proyecto que se va a realizar. Esto pasa por colocarle un título, definirlo, plantear
un alcance, asignar unos recursos, acordar unos entregables y establecer una expectativa de
horizonte temporal. La idea es concretar de alguna manera la visión compartida por los que
requieren de la solución y por los encargados de desarrollarla.

Iniciar un proyecto sin esta visión compartida, expresada en forma clara y para todos los
involucrados, conduce a una fricción que se hace inevitable cuando lo que obtengan los
desarrolladores no sea lo que esperaban en su imaginario, realista o no, los potenciales
usuarios. Los desacuerdos entre quienes construyen una solución y quienes la solicitaron
muchas veces son el resultado de no haber hecho un buen comienzo: una definición explícita
de qué es lo que entiende cada parte por el trabajo a realizar y por la manera de desarrollarlo
y entregarlo. Por eso, si es importante una Arquitectura de Información bien estructurada, el
primer paso es la definición del proyecto como un acuerdo explícito de visión en un lenguaje
compartido por los desarrolladores y sus contrapartes. Esto no asegura un resultado exitoso y
una relación armónica, pero abre la posibilidad de estos logros.

En proyectos de cierta complejidad, sin embargo, incluso después de haber escrito la visión
compartida en forma explícita, puede ser bueno no acordar el desarrollo completo de la
solución, sino sólo la primera de sus fases: la conceptualización.