viernes, 14 de diciembre de 2012

Mensaje de Navidad 2012



Nos vemos de nuevo en enero 2013, después de la llegada de los reyes.

viernes, 30 de noviembre de 2012

¿Que hacemos después de definir la Arquitectura de Información?

Una manera de construir soluciones de gestión de información es a través
 del desarrollo  de software. Los gerentes de información deben ser cautos
en todo lo que ello implica

Quienes nos han seguido a través de este blog seguramente se han involucrado en problemas de gestión de información que han demandado la definición de una solución con conceptos de Arquitectura de Información. El trabajo, como hemos visto, implica un movimiento en cinco dimensiones: Estructura, Funcionalidad, Navegación, Seguridad y Estética. A cada una de ellas le hemos dedicado varios post. Ahora bien, así como tener los planos de una casa no significa tener la casa construida, sino sólo eso, los planos, saber cómo debe conformarse una solución de gestión información no significa tener el trabajo hecho. Pero si la mejor guía para hacerlo. A partir de ese punto vienen entonces otros problemas: ¿cómo construimos la solución y cómo aseguramos su calidad?

Hay múltiples caminos. Uno de ellos, relativamente establecido es el de la Ingeniería de Software. Después de algunas décadas de prácticas sin definir un cuerpo de conocimientos generalmente aceptado de la Ingeniería de Software, dos organizaciones de gran relevancia internacional, la ACM y la IEEE, se dieron a la tarea de establecer, con gran detalle, el trabajo intelectual realizado por los practicantes de esta Ingeniería. Esta actividad condujo a definir el cuerpo de conocimientos que deben manejar estos ingenieros, obteniendo como resultado un compendio articulado de diez áreas de conocimiento:

  • Requisitos de Software
  • Diseño de Software
  • Construcción de Software
  • Pruebas de Software
  • Mantenimiento de Software
  • Gestión de la configuración
  • Gestión de la Ingeniería de Software
  • Proceso de Ingeniería de Software
  • Herramientas y métodos de la Ingeniería de Software
  • Calidad del Software

Aún sin entrar en detalles de lo que significa el trabajo en cada una de estas áreas, es claro que la alternativa de obtener una solución de gestión de información a través del desarrollo de software es una opción sofisticada, que exigirá tiempo, recursos y un trabajo técnico muy especializado, por lo que sólo debe asumirse seriamente cuando se esté claro en cuál es el aporte que se obtendrá por esta vía.

Es importante saber, en este contexto, que hoy día hay otras opciones variadas y que, afortunadamente para los gerentes que están a cargo de los procesos, solucionar un problema de información ya no es sinónimo de desarrollo de software. Más delante volveremos sobre esas otras opciones más sencillas, basadas en herramientas o servicios donde se configura directamente la solución en forma rápida. Este tipo de alternativas puede usarse para construir prototipos funcionales, incluso cuando se piensa que la solución específica y definitiva al problema se obtendrá a través de software, ya que un prototipo funcional construido en forma rápida permite visualizar mejor lo que se obtendrá y, por tanto, adecuar más consistentemente la solución.

La coherencia en la interfaz es fundamental

Muchas veces las personas no se caen por casualidad,
sino como consecuencia de un detalle mal diseñado
o mal construido
 (imagen tomada de http://www.ccohs.ca/oshanswers/safety_haz/)

La coherencia es la cualidad que expresa la ausencia de contradicciones. La relación conectada de unas cosas con otras. La lógica respecto a lo anteriormente mostrado. Una interfaz de usuario coherente le proporciona a éste una manera consistente de trabajar, de hacer las cosas, de relacionarse con un sistema, de autenticarse, de buscar información, de recuperarla, de cambiar su presentación. Así pues, uno puede preguntarse, con mucho sentido, hasta que punto la coherencia es importante, por qué lo es y cómo se trabaja esta importante cualidad en el proceso de desarrollo de una solución de gestión de información.

Muchos hemos visto a alguien que se cae en unas escaleras en un ambiente público. Sin embargo, son pocos los que han tenido la oportunidad de participar en una reflexión de por qué una persona se cayó. Una actividad siempre conveniente porque, con cierta probabilidad, la escalera donde alguien se cae no es completamente consistente y es posible que haya algo estructural en ella que no funcione bien.

No siempre, desde luego. Una persona puede caerse porque estaba mareada o por cualquier otra condición interna, permanente o circunstancial, pero en todo caso independiente del entorno. Pero hay muchos casos en que lo que ocurre es que los incidentes se producen allí donde hay una cierta falta de coherencia. Si hay un punto de la carretera donde los vehículos chocan con más frecuencia, allí hay un problema. Otra vez en el caso de la escalera, un escalón que tiene una altura o un ancho diferente al resto suele ser el responsable de muchas caídas. ¿Por qué?

Porque hay un momento en que las personas suben o bajan guiadas por un cerebro que confia en que lo que sigue es análogo a lo anterior y no se requiere más procesamiento. Este es un comportamiento que en general funciona, pero no en el caso de incoherencias como un escalón que aparenta ser igual pero es distinto.

En estos días observamos a una persona mayor intentando usar un teléfono celular inteligente con un sistema operativo de última generación que lucía muy funcional y consistente. El móvil tenía además una interfaz táctil moderna con capacidad de reconocer múltiples toques simultáneos. La persona en cuestión aprendía a manejar el dispositivo a pesar de que era realmente diferente a toda su experiencia previa en el uso de teléfonos, fijos o móviles. La interfaz táctil era una novedad completa, que a veces requería de él tocar la pantalla, pero otras veces desplazar el dedo sobre ella, respondiendo a los cambios de la información presentada. El punto es que nuestro usuario, de la tercera edad, le costaba recordar como era que agregaba una personas a su lista de contactos. Lo vimos usar su nuevo teléfono y comprendimos el problema: La función de agregar usuarios, básica por demás, presentaba una discontinuidad en la interfaz. Tenía sólo un icono, sin una palabra descriptiva como el resto de la interfaz. En dos palabras: ¡era incoherente!

Seguramente un usuario con más experiencia digital hubiese podido descubrir la funcionalidad escondida, pero lo importante como aprendizaje es que siempre que vemos a alguien caerse por una escalera que nosostros diseñamos o construimos es conveniente analizar el hecho, en un intento por descubrir si hay algo que podría prevenir esa caída.

En nuestra experiencia la coherencia en una interfaz tiene varias virtudes, genera confort y seguridad en el usuario y por ello mejora su eficiencia y eficacia. Recordamos como otro ejemplo los tempranos días de la Web, cuando aún había pocas prácticas estandarizadas de diseño de la interacción con el usuario. Muchas de las compras en línea no se concretaban simplemente se perdían simplemente porque la gente se perdía en el camino.

¿Cómo es la manera de hacerlo bien? En el momento del diseño, buscando ser muy coherente y dándole valor a la experiencia previa que esperamos del usuario. Y una vez liberado el servicio, observando las escaleras y los escalones donde la gente se cae, allí está el aspecto mejorable y el lugar donde debemos tener nuestro aprendizaje.

jueves, 22 de noviembre de 2012

Todas las audiencias están cambiando

Los nativos digitales interactúan en forma radicalmente diferente de los
 inmigrantes digitales y su presencia es cada vez más significativa entre nuestros
usuarios. Esta realidad tiene implicaciones para los Arquitectos de Información

Uno de los hechos que todos los Arquitectos de Información y diseñadores de soluciones informáticas debemos tomar en cuenta son los cambios que se han operado en la humanidad, como conjunto, luego de más de dos décadas de la Internet pública y de uso intensivo de la World Wide Web. En la práctica, este cambio se refleja en modos de interactuar diferentes a los anteriores y que se usan en todo el mundo, en todas las audiencias, en todas las aplicaciones. El porcentaje de nativos digitales, es decir, de personas que desde jóvenes se han habituado al uso de dispositivos digitales, redes e interfases gráficas es ahora significativo en todos los casos, y mayoritario en muchos de ellos. Es cada vez más difícil encontrar adultos contemporáneos que no hayan usado la Web por muchas horas, con gran facilidad o con algunas dificultades. Por ello actualmente se hace crecientemente válido suponer que nuestros usuarios están habituados a la exploración y la navegación digital con las interfases características de la Web. Esta suposición tiene consecuencias interesantes.

Los seres humanos nativos digitales son muy diferentes de los inmigrantes digitales, aquellos que nacieron y crecieron con poco contacto con los dispositivos del mundo digital y los han ido aceptando en el camino porque son parte de la era moderna que nos tocó vivir.

Éste es un hecho es relevante porque es tan marcada la diferencia que la manera de reaccionar ante los estímulos, de captar el mundo exterior, de razonar, de articular, de actuar frente a cualquier cosa, y claramente ante un dispositivo digital, es tan distinta ahora que los diseñadores de soluciones en un mundo en transición tienen que darse cuenta como han variado y siguen variando sus audiencias. Éstas esperan y  incluso exigen estrategias de interacción totalmente diferentes, más basadas en imágenes y con más posibilidades de navegación personalizada y de alternativas para adaptarse a las características particulares del público nativo digital.

Es interesante que el célebre paper de Marc Prensky, “Nativos digitales, Inmigrantes Digitales” (Digital Natives, Digital Immigrants, MCB University Press, 2001) ya tiene más de diez años. En ese momento el autor advertía como había que despertar y darse cuenta que los nativos digitales eran seres diferentes: “Nuestros estudiantes han cambiado radicalmente. Los estudiantes de hoy no son ya el tipo de personas para las cuales nuestro sistema educativo fue diseñado”. Bueno, lo que ocurre es que ha pasado más de una década desde entonces y los que eran estudiantes en el 2001 ya hace rato que salieron del sistema educativo y están en todos los muy diferentes puestos de trabajo que pueblan la escala ocupacional de la sociedad.

Esta gente con el “cerebro diferente” están integrando nuestras audiencias de hoy, son parte significativa de nuestros usuarios. Por eso es conveniente que repasemos algunas de sus características distintivas y entendamos a partir de allí la necesidad de diseñar en forma diferente la experiencia del usuario. Incluso cuando la funcionalidad sea la misma, debemos desarrollar arquitecturas de información diferentes, con esquemas de navegación, de imagen y de estética distintas y, probablemente, con algunos elementos estructurales también diferentes, simplemente porque nos dirigimos a personas que usan en su cotidianeidad códigos distintos para comunicarse, para pensar y para interactuar.

Es una realidad que la gente de hoy actúa más rápido, menos paso por paso, con más tanteo, con más pensamiento gráfico y paralelo, y más caminos basados en la intuición. Es una realidad que los clásicos manuales, escritos al estilo de antes, han dejado de producirse y ya nadie los mira y es importante darse cuenta de que no lo hacen porque, sinceramente, actualmente no se necesitan.

viernes, 16 de noviembre de 2012

La Proliferación de Dispositivos

Actualmente proliferan una gran cantidad de dispositivos,
siguiendo una secuencia donde se alternan las tendencias
a la diversidad y lo particular con las tendencias a la
 estandarización, sin que haya una solución universal,
válida siempre

Si analizamos el uso que le damos a las Tecnologías de la Información para manejar nuestros activos de información, podemos apreciar como, en ocasiones, desarrollamos tendencias convergentes, en las que adoptamos pautas de estandarización que nos ayudan a avanzar con mucha eficiencia a través de prácticas donde el componente común es muy importante en el resultado. También desarrollamos tendencias divergentes, donde nos apartamos de los estándares y nos dispersamos en maneras distintas de hacer las cosas. En estos casos el peso de los componentes genéricos de las soluciones disminuye, hasta un punto, más adelante en el tiempo, en que el reconocimiento de buenas prácticas se imponen de nuevo creando modos de hacer las cosas generalmente aceptados. Damos en este post algunos ejemplos y comentamos cómo nos está afectando la actual proliferación de dispositivos en el desarrollo de la imagen y estética que incluimos en nuestras soluciones de información.

Veamos rápidamente algunos cambos históricos: el procesamiento manual de la información lo fuimos sustituyendo por un procesamiento automatizado, desde los albores de la computación. Al principio los equipos eran grandes, costosos y pesados y la práctica era alquilarlos. Luego desarrollamos soluciones más simples y económicas y esto nos fue permitiendo generalizar la adopción de computadores en más lugares e instituciones.

Estas soluciones eran disímiles hasta que se estandarizaron en el procesamiento por lotes (batch), no interactivo, con lenguajes de programación definidos que fueron el principal componente genérico, ya que los sistemas operativos eran diferentes. En la época había poco que hacer con la estética de las soluciones y lo que privaba era la solución práctica al problema de procesamiento de información.

Luego vino la ola de los minicomputadores y los terminales interactivos. Con el Unix adquirió fuerza y terminó imponiéndose la idea de estandarizar también los sistemas operativos, dejando a los fabricantes las diferencias en el hardware. El punto culminante de esta línea de estandarización quizá fueron las estaciones de trabajo conectadas en red.

Con los microcomputadores hubo de nuevo otra tendencia divergente. Volvimos a perdernos en multitud de equipos y soluciones diferentes hasta que la ola de estandarización se hizo clara luego del advenimiento del IBM PC que estableció las pautas para el hardware del escritorio y más adelante Windows que se convirtió en un estándar de facto para los sistemas personales.

La computación fue haciéndose gráfica y se desarrollaron las redes. La Imagen y estética comenzó a ser definitivamente importante. Al principio los esquemas eran de nuevo divergentes, hasta que la Internet se convirtió en un estándar de conectividad al punto que se hizo inconcebible pensar en un computador que no estuviera conectado y en una red que no fuera Internet Este movimiento llegó a una zona especial por la amplitud de los resultados. En efecto, la WWW evolucionó como la plataforma ideal para compartir todo tipo de contenidos, estandarizando primero la búsqueda y la salida y luego todo el ambiente de trabajo de todas las aplicaciones.

De esta manera llegamos a los 90 con redes, con microcomputadores estandarizados, con redes estandarizadas a través de Internet y con la Web como un esquema universal de compartir la información y de desarrollar la interacción.

La Internet llegó a los teléfonos, que se habían hecho inalámbricos en forma paralela. Se ha venido tragando a éstos, que dejaron de ser una solución genérica para convertirse, con los dispositivos móviles, en un universo de aparatos variados. Los celulares terminaron la tarea de imponer la digitalización en las fotografías y las imágenes. Otra vez comenzamos con sistemas heterogéneos para recorrer nuestro camino de unificarnos hacia unas pocas opciones genéricas.

Han vuelto a proliferar los dispositivos, la electrónica permite hacerlos de múltiples formas y tamaños, los precios los hacen asequibles a muchas personas y hay cantidad de nuevas soluciones. Las interfases se hacen táctiles y por eso el actual panorama de la interacción en teléfonos, tabletas y ultra notebooks es demasiado diverso para ser manejado con eficiencia. Esta ola dispersiva parirá nuevas soluciones genéricas que volverán a facilitarnos muchas cosas, entre otras, la estandarización de la interacción y el desarrollo de una imagen y estética coherente en la diversidad de aplicaciones.

viernes, 9 de noviembre de 2012

La resolución de las imágenes



El concepto de resolución: La foto de arriba tiene sólo 60 pixeles por pulgada (ppi),
mientras la de abajo tiene cuatro veces mas: 240 ppi. Se oberva la diferencia de calidad.
La foto está tomada del sitio de Adobe
Es un hecho que las nuevas generaciones están mucho más propensas a la interacción a través de imágenes. Esto nos obliga a todos los Arquitectos de Información a diseñar en forma creciente la experiencia del usuario a través de una comunicación con íconos y a hacer numerosas consideraciones estéticas en un ambiente de desarrollo de aplicaciones que dista mucho del que manejábamos hace unos años, donde la comunicación de los usuarios con los sistemas estaba más basada en palabras y menús jerárquicos. Este hecho no es tan trivial como parece y se complica con la proliferación de dispositivos de tamaños y capacidades muy diferentes. Así como un Arquitecto diseñador de viviendas debe saber un poco acerca de los distintos tipos de materiales y técnicas de construcción usadas con ellas, así un Arquitecto de Información debe conocer un mínimo acerca de algunas de las propiedades esenciales de las imágenes.

Lo anterior no significa que, al menos por ahora, las interfases de comunicación deban ser sólo íconos, imágenes y gráficas. Lo que si significa es que no basarse sólo en la expresividad de las palabras y que hay complicaciones muy grandes para adaptarse a los distintos patrones de trabajo de nuestros usuarios y las distintas características de los dispositivos. En medio de toda la etapa de transición que vivimos, hay parámetros técnicos que es conveniente manejar.

Uno de los problemas que se presenta al planificar una interacción basada en elementos visuales, no textuales, es que debido a que las imágenes tienen que viajar a través de la red, ocupando por algunos instantes el canal físico de comunicación, el tamaño de las mismas puede afectar la calidad de la interacción. Contrariamente a lo que el sentido común no formado dice, el tamaño de una imagen puede o no guardar relación con el tamaño físico de ésta y su calidad estética. Antes bien, el tamaño, medido en el espacio de memoria que se requiere para almacenarla o para comunicarla, es una función de múltiples factores.

La resolución, el algoritmo de compresión usado, la cantidad de colores y la complejidad misma de una imagen pueden incidir en su tamaño.

La resolución es la cantidad de pixeles o puntos del dispositivo de presentación que se requieren para mostrar una fracción de la superficie de la imagen. Mientras más densa es la resolución, más puntos se dibujan por unidad de superficie y por tanto más pesada es la imagen. El problema cotidiano de gestión de imágenes se dificulta porque no hay una resolución óptima de trabajo. Las pantallas funcionan con baja resolución y el papel con alta. Si para mostrar en pantalla usamos la misma imagen que para imprimir, enviamos por el canal mucho más de lo que se necesita, lo cual puede implicar tiempo (de espera para cargar las imágenes) y/o dinero, si por ejemplo, se está conectado a través de uno de esos enlaces que se pagan por Megabytes. Si para imprimir usamos imágenes de baja resolución, estas podrían verse bien en pantalla, pero mal impresas.

También la aplicación importa. Las buenas prácticas de comunicación a través de correos electrónicos exigen que no se envíen imágenes muy grandes y pesadas porque cargan innecesariamente ese canal. En una página Web pueden usarse imágenes de mayor calidad, pero tampoco mucha resolución, porque después de un cierto punto ni las pantallas ni el ojo humano manejan las diferencias. Finalmente, en documentos para impresión se requiere que las imágenes tengan mayor calidad (y resolución) en los casos (que no son todos) en que la naturaleza del medio permite diferenciarlas.

Todo esto puede obligar a tener almacenadas o ser capaces de generar instantáneamente varias versiones de la misma imagen. Otro factor que es bueno conocer es que no es fácil devolverse. A partir de una imagen de baja resolución no podemos recrear la imagen de alta resolución original, por esta razón, muchas veces los sistemas almacenan imágenes con alta resolución que, cada vez que se requieren, convierten a la resolución adecuada al canal, el dispositivo y la aplicación con la que se trabaja.

Finalmente hay que señalar que no siempre una imagen de más resolución tiene más calidad. Hay teléfonos que toman fotos de alta resolución, pero baja calidad. Tampoco es cierto que se mejore necesariamente la estética, ya que ésta corre por una pista que si bien no es completamente paralela, si tiene gran independencia. Así pues, como vemos, hay detalles que el Arquitecto de Información debe manejar sobre las imágenes...

viernes, 2 de noviembre de 2012

El lenguaje de las imágenes



Los iconos de una aplicación conforman un lenguaje.
En algun momento del desarrollo hay que colococarlos
juntos para estudiar sus propiedades, afinidades y
desafinidades, tamaño, estética, proporciones,
características técnicas, simbólicas y semióticas
La humanidad ha venido cambiando en muchos de sus procesos cotidianos por efecto del uso que hacemos de las tecnologías de la información, así como por las características gráficas presentes en los aparatos que usamos en nuestra cotidianidad. Estas tecnologías, estos aparatos y la globalización que impone pensar en mercados mundiales, y por tanto, minimizar los problemas de comunicación ante la diversidad de idiomas naturales, han llevado a una comunicación entre los sistemas de información y el ser humano mucho más basada en imágenes. No cabe duda que la importancia de lo visual ha subido en el diseño de los sistemas y esto trae implicaciones de múltiples tipos, cuando vamos al punto concreto del desarrollo de sistemas con una Arquitectura de Información bien definida.

Debemos saber que la mayoría de los usuarios modernos espera salidas con imágenes, con iconos. Hay un lenguaje de iconos que tiene una carga semántica. Los sistemas modernos usan íconos para identificar contenidos, servicios, acciones, aplicaciones. Eso de alguna manera establece las características de la cancha donde corren los diseñadores de la imagen y estética y de la experiencia del usuario. Hace que nos tengamos que preguntar, ante cada sistema, ante cada solución de procesamiento de información, cuáles son los íconos con los cuales vamos a identificar los tipos de contenidos, los servicios, las acciones.

Es claro que un sistema podría realizar su trabajo funcional sin estos íconos, pero lo que también es claro es que la probabilidad de que la interacción con el usuario no sea la adecuada se hace demasiado alta si la importancia de estas imágenes se ignora. El lenguaje de los iconos se convierte, así pues, en coadyuvante de la funcionalidad, de la navegación, y condiciones de borde para la definición de la estética de una solución informacional moderna.

Si nos fijamos, cualquier aplicación, por pequeña que sea, termina definiendo un lenguaje de imágenes que incluye varias decenas de iconos. No es para nada extraño que la cantidad pase del centenar en sistemas con mayor complejidad.

¿Qué implicaciones tienen estos hechos para el diseñador de la Imagen y estética de una solución y para la institución que la requiere?

Muchas. Entre otras se tiene el hecho de que al igual que una nota musical no se puede colocar de cualquier manera al lado de otra porque el conjunto puede sonar bien o mal, ser o no apropiado, y transportar o no el mensaje de emociones deseado, un ícono no se puede colocar de cualquier manera al lado de otro porque puede que no combinen, que el conjunto se vea mal. Por supuesto vamos desde los casos simples y de obviedad a los casos complejos, menos evidentes. Lo cierto es que en algún momento hay que colocar todos los íconos juntos, observarlos como conjunto articulado y detenerse para explorar su compatibilidad en tamaño, estética, proporciones, características técnicas, simbólicas y semióticas.

Hay un lenguaje de afinidades y desafinidades en las imágenes que se usan en una solución. Este lenguaje no lo es todo, pero es una parte importante. Hay que estar claros en que cuando tengamos los iconos que requiere una solución no tendremos diseñada la estética de una solución informacional, ni  la comunicación, ni la experiencia del usuario, ni la navegación. Pero tendremos lista una parte necesaria que en la actualidad no se puede eludir.

Esto significa que, así como un Arquitecto de construcciones civiles muchas veces requiere de un dibujante técnico, un Arquitecto de información y un gerente de servicios de información siempre tienen que tener cerca, muy cerca, a un diseñador gráfico y/o un comunicador social con la formación adecuada para entender estos temas.

viernes, 26 de octubre de 2012

La Imagen y Estética deben ser paralelas



Cuatro capturas de pantallas desde
 http://www.zengarden.com
El contenido es el mismo, por lo que éstas pantallas
muestran como con hojas de estilos de HTML (CSS)
se pueden lograr efectos muy diferentes en la
 presentación de contenidos.
Hace un par de semanas retomamos la conversación de Arquitectura de Información en el tema de la Imagen y la Estética. Planteamos el carácter que este área de trabajo tiene para el Arquitecto de Información y discutimos como no se trata sólo de lograr el deleite ante lo bello, como un atributo complementario a lo bueno y lo funcional, sino que más allá de eso, se trata de lograr que la estética contribuya a la funcionalidad, a la navegación, a la usabilidad de la solución de gestión de información que se diseña y desarrolla. Hoy queremos insistir en el carácter paralelo que debe tener el trabajo estético dentro de la Arquitectura de Información. Cómo y por qué hay que lograr que éste sea desarrollado con bastante (y mejor si total) independencia del trabajo de estructuración de contenidos, despliegue funcional, establecimiento de la navegación y seguridad informacional.

Cuando comenzó la Web, en los inicios de los 90, este conocimiento no se tenía muy claro y todavía mezclábamos estructura, con contenidos y atributos estéticos y de imagen. Eran muchas menos las posibilidades para los diseñadores y era mucho lo que tenía que hacerse a través de programación.

Las hojas de estilo de HTML (CSS) fueron el gran salto que permitió avanzar de una manera clara y lograr que la Imagen y Estética de una página Web pudiera establecerse en forma completamente independiente de su contenido (Ver en Aprendizajes y formatos un poco más acerca de esta historia). En efecto, gracias a los estilos de HTML hoy podemos desarrollar la Imagen y estética en forma paralela al trabajo en las otras dimensaiones de la Arquitectura de Información: Estructura, Funcionalidad, Navegación, Usuarios y Seguridad (Ver: Las cinco dimensiones de la Arquitectura de Información). Desarrollo en paralelo significa aquí la posibilidad de avanzar en caminos que corren uno al lado del otro, sin entrecruzarse, y por tanto, sin que uno obstaculice o frene el avance en el otro.

Los estilos de HTML permiten cambiar muchos elementos estéticos: fondos, color, alineación, decoración y espaciado de textos. Familia, estilo, peso y tamaño de fonts.  Características de presentación de imágenes, enlaces, listas y tablas.

El mismo contenido Web puede lucir completamente diferente si lo presentamos con hojas de estilo diferentes. Gracias a estas hojas de estilo los Gerentes y los Arquitectos de Información pueden trabajar con diseñadores Web los elementos estéticos mientras (en paralelo) avanzan en las otras dimensiones del desarrollo de la solución de gestión, por ejemplo, la funcionalidad y la navegación.

En las imágenes mostramos un ejemplo que desde hace algunos años hizo clásica la ilustración de cómo se podía lograr un resultado muy diferente en la presentación del contenido de una página Web a través del cambio de la línea que en el documento HTML especifica la hoja de estilo CSS que debe usarse al presentar el contenido: http://www.zengarden.com. La primera página es el contenido sin estilos y las siguientes tres muestran el mismo contenido con hojas de estilos diferentes.

Obviamente, desarrollar una aplicación o resolver un problema de gestión de la información no es algo tan simple como diseñar una página Web. Si se permite la metáfora: no es lo mismo pintar bien una pared que diseñar bien una buena casa, si bien la construcción de una buena casa, hecha a partir de un buen diseño, requiere el saber cómo pintar las paredes para que éstas luzcan bien.

Generalizando el concepto de estilos CSS en la familia de páginas Web que integran un sitio dinámicamente construido, y separando en una base de información los contenidos de los aspectos estructurales, de seguridad, de funcionalidad y de navegación, se tienen todas las piezas de un lego del cual se pueden cambiar muchos elementos para lograr resultados específicos en las salidas, sin tener que programar y con gran independencia del trabajo en las distintas áreas. Así debe manejarse la estética de un sitio Web. Eso es lo que significa el trabajo paralelo. Lo absolutamente contrario es entregar los contenidos a un diseñador y esperar que nos resuelva la construcción de las páginas Web, práctica que lamentablemente todavía se realiza en muchos sitios.

viernes, 19 de octubre de 2012

El diseño de la Imagen y Estética

Las Torres Petronas en Malasia: Al comenzar a diseñar la imagen de
un sitio Web los Arquitectos de Información tienen que hacerse
preguntas análogas a las que se hacen en una oficina de Arquitectos
cuando se comienza el diseño de una nueva edificación icónica

Al hablar del diseño de la Imagen y estética como la quinta dimensión en el trabajo de Arquitectura de Información la semana pasada expusimos cómo esta actividad cumple un rol que trasciende el disfrute complementario de la belleza que siempre hacemos, en cualquier área, una vez que están satisfechas todas nuestras necesidades previas. Señalamos que el trabajo en esta dimensión se integra en lo práctico, lo funcional y lo fácilmente navegable que una solución informacional puede o no ser para el usuario para el que fue desarrollada. Entramos hoy con más detalles para ilustrar los procesos típicos que deben realizarse a la hora de acometer el diseño de una solución informacional.

La primera consideración que hay que hacer cuando se diseña la Imagen y Estética de una aplicación o sistema de gestión de información tiene que ver con la diagramación de la salida. Recordemos que no está bien simplemente soltar una secuencia indiscriminada de textos y enlaces para que el usuario sobreviva entre ellas y encuentre lo siguiente que quiere leer o hacer, casi obligado a pasarse por todo el contenido presentado. No es así como trabajan los sitios Web exitosos. Antes bien, hay ciertos esquemas de diagramación que tienden a repetirse y que permiten que el usuario de una solución se ubique más o menos fácilmente en los contextos. La creatividad de los buenos diseñadores subyace dentro de estos parámetros. Si se trata de un diseño para un equipo de escritorio o de una laptop, normalmente la pantalla se divide en secciones con un encabezado y dos o más columnas. Típicamente con un pie. A veces con algunas secciones adicionales, claramente identificables (Ver Las áreas básicas de la salida).

En numerosos casos se usa un esquema de diagramación especial para la página inicial (Ver La página inicial) y un esquema (o varios, cuando es necesario) para las páginas interiores. Esto lo estudiamos con detalles cuando consideramos la tercera dimensión del trabajo de Arquitectura de Información: la Navegación (Ver). De lo que se trata a partir de la determinación del modelo de diagramación que se usará es el establecer unas normas o patrones gráficos que incluirán imágenes y selección de colores de fondo de cada una de las secciones integrantes de cada esquema y los tipos de letras principales que se usarán, con sus respectivos atributos y colores.

Un modo que muchas veces resulta apropiado es pensar que toda salida está compuesta de secciones y que cada sección está compuesta por celdas y cada celda informacional normalmente contiene un título, una imagen, un contenido y un enlace. Adicionalmente otros elementos como subtítulos y otros enlaces. Con esto en mente se definen los principales estilos de HTML que se usarán. En cuanto al tipo de contenido que se mostrará aplica el concepto de tipo de salida que también trabajamos en otras oportunidades (Ver En los tipos de salida, todos los sistemas se parecen). Estos tipos de salida pueden requerir la definición de estilos adicionales de HTML.

Trabajando de esta manera pueden diseñarse los aspectos gráficos y estéticos de una solución con bastante independencia de los contenidos específicos que en un momento dado se presentarán. Debe notarse que es un error atar el diseño estético a los contenidos específicos ya que por una parte, si un sitio Web trabaja bien, sus contenidos deben variar con mucha más frecuencia que su diseño gráfico y por la otra, un sitio Web bien diseñado debe poder cambiar su imagen y estética con total independencia de los contenidos.

Obviamente hay diferencias claras entre un sitio Web corporativo para los miembros de una empresa y un sitio abierto al amplio público. Entre un sitio para profesionales y un espacio digital para jóvenes. Sin embargo, hay elementos comunes. Por ejemplo, sin que hayan normas escritas en piedra, un sitio Web debe variar integralmente su imagen general al menos una vez al año y sus contenidos con una periodicidad claramente definida para general interés y seguridad a sus audiencias.

viernes, 12 de octubre de 2012

¿Por que considerar la estética?

Bahrain World Trade Center:
El diseño de las edificaciones modernas intenta
permanentemente fundir lo bello con lo práctico,
funcional y ecológico
(foto tomada de http://www.skyscrapercity.com)

La semana pasada retomamos la conversación de las cinco dimensiones de la Arquitectura de Información (Estructura, Funcionalidad, Navegación, Comunidades-Seguridad e Imagen-Estética) y en particular, hicimos una introducción a la quinta de estas dimensiones: La Imagen y Estética. Queremos hoy detenernos en la consideración de por qué es un deber del Arquitecto de Información el incorporar en sus análisis y diseños consideraciones estéticas. Esperamos mostrar que más allá de lo que muchos creen, el valor de este trabajo no reside meramente en el hacer los sitios Web más bonitos. En lugar de ello veremos que la estética tiene otras funciones sobre las que descansa su importancia para el Arquitecto y el Gerente de un servicio de Información.

Todos estamos claros que la belleza incluye ingredientes subjetivos y culturales. Que lo que nos parece bello a algunos no necesariamente le parecerá bello a otros. También que por A o por B hay elementos que pueden inspirar ciertas sensaciones de belleza a colectivos mayores o menores. Pero independientemente de esos detalles, la belleza está directamente vinculada con el confort, con el sentirse bien. Esto quiere decir que, a igualdad de condiciones funcionales, nos sentimos mejor en situaciones donde apreciamos que hay belleza.

No significa esto, desde luego, que la belleza sea un sustituto de la funcionalidad. La pura belleza no resuelve las necesidades y aunque estemos en presencia de algo muy bello, podemos estar muy incómodos, si estamos en una situación completamente infuncional y algunas de nuestras necesidades no están satisfechas.

Lo anterior podría ser suficiente para motivar a los Arquitectos de Información para diseñar con consideraciones estéticas, ya que con una razonable capacidad de resolver sus problemas funcionales de manejo de información, la gente se sentirá mejor si el sitio Web le resulta atractivo. Pero decirlo así es insuficiente y subestima el resultado al que debe aspirarse cuando se trabaja en la quinta dimensión de la Arquitectura de Información, y ese es el punto al que queremos ir.

Las pantallas de los sistemas modernos son gráficas y a color. Pueden ser pequeñas o grandes según el dispositivo que se use para consultar, pueden ser de interfaz de teclado o táctil, pero lo que es cierto es que bien sea un teléfono, una tablet, una laptop, la salida de un proyector sobre una pared, o la de un dispositivo de escritorio, los contenidos se presentarán en una pantalla susceptible de ser diagramada gráficamente y de presentar el mismo contenido con colores y ubicaciones variados según una cantidad de parámetros. Y según como lo hagamos, los pasos naturales para el usuario será más visibles o menos, más claros o menos claros, autoexplicativos o difíciles de encontrar.

Visto de esta forma entendemos que lo que podrían ser meras variables estéticas: fondos, imágenes, colores, tipos de letras, tamaños relativos, inclinaciones, disposición en el espacio, etc. terminan siendo colaboradores inseparables de la comunicación con el usuario, de la utilidad percibida, de la funcionalidad y la navegabilidad de una solución, es decir, determinantes claves de la experiencia del usuario, en un sentido práctico y utilitario.

La satisfacción de nuestras audiencias ante un diseño está, por tanto, ligada al trabajo realizado en la dimensión de Imagen y estética de una manera mucho más importante, crucial y definitoria, que el simple disfrute ante lo bello, complementario a una necesidad resuelta. Por eso esta dimensión (Ver Imagen y estética: la quinta dimensión de la Arquitectura de información), y la formación que conlleva para el Arquitecto de Información, es importante, y aún tendremos que entrar en más detalles…

viernes, 5 de octubre de 2012

Imagen y estética: la quinta dimensión de la Arquitectura de información

La Casa de la Opera de Sidney. Sin duda una maravilla arquitectónica:
Funcional y Estética. Una muestra excelente de como hoy no consideramos
suficiente la mera funcionalidad. Esto ocurre en la construcción civil, pero
 también en los sistemas de Información. Los Arquitectos de Información
deben trabajar también la quinta dimensión: Imagen y Estética

Recordemos que hace unos meses explicamos como la Arquitectura de Información era el resultado de un trabajo necesario que se hacía a través de cinco dimensiones: Estructura, Funcionalidad, Navegación, Comunidades (y seguridad) e Imagen (y Estética). Nos detuvimos algunas semanas en cada una de ellas. Pues bien, a partir de hoy queremos entrar en la conversación de la Imagen y Estética y describir, comprender y aquilatar esta quinta dimensión de la Arquitectura de Información.

Recordemos rápidamente por qué hemos usamos el concepto de dimensión y no simplemente de hablamos de variables: Queremos reflejar al mismo tiempo la complejidad, la infinitud y la autonomía con las que se trabaja en cada uno de estos espacios conceptuales.

En efecto, en cada una de estas dimensiones hacemos análisis especializados y tomamos en cuenta múltiples variables, consideraciones y definiciones estrechamente relacionadas, a sabiendas de que podemos intervenir en los aspectos vinculados ese espacio conceptual dentro del resultado final, sin tener que involucrarnos con los elementos más directamente enraizados en las otras dimensiones. Por ejemplo, podemos cambiar la estética sin afectar la seguridad, la seguridad sin cambiar la estructura, o la navegación sin afectar la funcionalidad o la estructura informacional. Por eso es que hablamos de dimensiones y definimos el trabajo transdisciplinario que se hace en Arquitectura de Información como un espacio de cinco dimensiones.

Cuando los sistemas de información eran soluciones con las que el usuario interactuaba a través de terminales de caracteres conectados a un computador central en una cierta localidad, poco sentido tenía hablar de Imagen y Estética. Simplemente las limitaciones del medio privaban y la conversación se centraba en la funcionalidad, por cierto, relativamente escasa en comparación con lo que se hace y se espera que haga en una solución automatizada de hoy en día.

Pero ese tiempo pasó hace décadas. Los terminales se hicieron gráficos, vinieron los computadores personales, estos se conectaron en redes, las redes se interconectaron a su vez, se estandarizaron a través de Internet y vino la Web, ofreciendo una manera de trabajar hipertextual con la capacidad de establecer enlaces de cualquier tipo de contenido con cualquier tipo de contenido, haciendo toda la información ubicua y presentando siempre todo a través de pantallas gráficas. Hasta los contenidos textuales terminaron siendo gráficos, con fonts y características comunicacionales en los que se colaban inevitablemente consideraciones estéticas.

A partir de la Web el mundo y las soluciones de información fueron otra cosa. La funcionalidad dejo dejó ser suficiente. Así como hoy día no basta que una casa sea funcional para que nos sintamos cómodos en ella y esperamos y necesitamos consideraciones estéticas e incluso artísticas al punto que nos resulta impensable el diseño arquitectónico sin ellas, así en cualquier de solución informatizada contemporánea esperamos y necesitamos (y con toda razón) aspectos que tiene que ver con la estética de la solución, con su apariencia, con sus colores, con su armonía, con su tamaño, con la diagramación de cada una de las pantallas de la salidas, con los íconos que se emplean.

Todo esto con la ventaja de poderlos trabajar con especialistas que manejan las variables de esta dimensión sin interferir en el trabajo de lo que se define, hace o construye en las otras dimensiones. Pero no se trata sólo de que la solución sea bonita. Hay detalles y complejidades. Hay que entrar en ellos para entender, de modo que sobre el tema volveremos.

viernes, 28 de septiembre de 2012

¿Cuanto tiempo se espera por un usuario?

Los usuarios descansan, atienden llamadas y necesidades varias. Por
ello, para un Arquitecto de Información y un Responsable de Servicios
de Información, la pregunta de cuánto tiempo esperar por un usuario
que se ha ido es absolutamente pertinente

La seguridad informacional es un tema permanente, que hay que definir muy bien, y que, cómo hemos estado viendo, tiene una perspectiva informática y una perspectiva informacional. Los responsables de servicios de información saben que uno de los factores que tienen que tomar en cuenta cuando definen cómo van a trabajar la seguridad es el tiempo en que se espera por un usuario, luego que éste interrumpe su trabajo por cualquier motivo. Dedicamos este post a este problema, muy simple, pero a veces muy importante por sus implicaciones en la seguridad…

Efectivamente, el hecho sucede cotidianamente, múltiples veces, en todas partes, en todo tipo de interacciones. En sistemas cuyo servicios principales son públicos y en sistemas cuyos servicios son todos o casi todos privados. Siempre hay tareas que son restringidas a ciertas personas, las que tiene un determinado perfil. Estas personas deben identificarse, de alguna manera, por ejemplo, lo más típico, indicando su nombre de conexión y su contraseña. Los esquemas de autenticación pueden variar de un caso a otro, de una institución a otra. Pueden ser muy simples o pueden ser muy sofisticados. Pueden resolverse en términos de una aplicación o pueden que sean resueltos en términos de una institución. No faltan los casos en que la autenticación se resuelve en términos de una macro institución, certificadora de autenticación para múltiples instituciones, a través de Internet.

Pero independientemente de que el procedimiento sea simple o complejo, local o no, el usuario se autentica. ¿Qué pasa luego? Con esa autenticación se identifica su perfil y con este perfil el usuario tiene acceso a determinados tipos de contenidos y a determinadas funciones sobre esos contenidos. El problema aparece porque siempre ocurre que los usuarios abandonan el contacto con el computador, bien sea ocasionalmente o bien en forma más definitiva, y los descuidos abundan. A veces porque se pensó en volver rápido y luego se sucedieron incidentes que impidieron el propósito y a veces, simplemente, por olvido. No faltan las ocasiones en que el problema se presenta por ignorancia en el procedimiento.

La pregunta pertinente es ¿Cuánto tiempo se debe esperar por un usuario que no ha vuelto hacer contacto con el teclado o el ratón? No hay una respuesta única correcta, cinco minutos de espera pueden ser suficientes y más, algo intolerable. Pero otras veces se debe ser mucho más flexible y se deben poder esperar lapsos mayores. Incluso mucho mayores, hay sistemas que esperan todo el día y sólo exigen reautenticación al día siguiente. Lo cierto es que si el usuario debe poder leer varias páginas de contenidos o revisar una cantidad de relaciones equivalentes, hay que estar dispuestos a esperar. Adicionalmente, es muy típico hoy en día que los usuarios sean multitareas, que hagan varias cosas a la vez, que tengan varias ventanas abiertas. Este hecho obliga a ser más laxos en los tiempos de espera en detrimento de la seguridad.

En los casos extremos hay que exigir al usuario concentración y, si éste se va con su atención a otra ventana durante un tiempo mayor del permitido, se le penaliza obligándolo a autenticarse de nuevo al momento en que vuelva con su atención. Por ejemplo, si se trata de un sistema bancario, es lógico que así sea y que los umbrales sean menores que otros que manejan contenidos menos delicados.

En el futuro, los sistemas biométricos sabrán quién es la persona que está al frente, pero lo que está claro es que hoy un Arquitecto de información y un Responsable de servicios deben poder conversar muchas cosas sobre seguridad, entre ellas, cuánto tiempo se espera por un usuario…

viernes, 21 de septiembre de 2012

Hay reglas generales de seguridad, pero a cada documento también se le da la palabra


Con Arquitectura de Información se diseñan reglas sobre tipos de documentos
 y comunidades. Pero cada instancia especifica de un tipo de objeto de
 información,  es decir,  cada documento concreto, tiene el derecho a convertirse
en una excepción.
Seguridad en tipos de documentos y en instancias de un tipo de documento. ¿Quién puede modificar qué? Continuando con las interesantes conversaciones acerca de la seguridad informacional hoy queremos analizar un poco más en detalle los elementos que intervienen en el cómo se toma la decisión de si el acceso a un documento se deja al alcance del usuario. Como veremos, las reglas generales cuentan, pero también lo que en específico dice el documento mismo acerca de quien puede acceder a su contenido, más allá del hecho que en un sistema o solución de gestión hay unas reglas generales para el acceso a cada tipo de documento, donde se toman en cuenta los perfiles de las distintas comunidades de usuarios y las características del tipo de documento en cuestión.

Como hemos estado viendo en las oportunidades anteriores, no hay una receta universal, sino orientaciones útiles a la hora de modelar sistemas de información. Los modelos no sólo tienen que permitir representar la realidad, también tienen que ser lo más simple posibles para que sean prácticos, entendibles por sus usuarios. Por eso se comienza siempre con unas reglas generales y simples que se van sofisticando a través de las iteraciones de diseño. Cada vez que se va a introducir un nuevo concepto o una nueva regla tenemos que revisar si ésta es necesaria o se puede vivir sin ella, porque mientras más simples sean los modelos de información que construyamos, más fácil será su mantenimiento.

Como hemos visto se comienza por establecer la estructura de cada tipo de documento y luego su funcionalidad. Luego se analizan la relación que ese tipo de documento tiene con cada comunidad de usuarios y se establece entonces lo que cada comunidad debe poder hacer con los documentos de ese tipo. Para atender a las personas que tiene varios perfiles o pertenecen a varias comunidades se define el modelo de seguridad con el que se trabaja (Ver: Seguridad informacional cuando se tienen varios perfiles). Todavía puede ser que hablar de modificación sea muy general y necesitemos introducir diferencias en los contextos lo que nos lleva a la necesidad de definir servicios de ingreso y modificación, como vimos la semana pasada ( Ver: El contexto del ingreso y la modificación de documentos y la seguridad informacional ).

Hablando precisamente de aspectos más sofisticados de la seguridad, vemos entonce que el acceso a un documento en específico puede depender de la conjunción de varios factores. Uno de ellos es el de si la comunidad a la que pertenece un usuario está autorizada o no para consultar o editar un documento de ese tipo, o en un sentido más general, si el modelo de seguridad y los perfiles que posee el usuario nos permiten considerar el acceso de éste a un documento de un cierto tipo.

Pero el cuento no acaba allí. El propio documento puede decir que, aunque en general este tipo de documento puede ser consultado por la comunidad de usuarios a la que pertenece su creador (o de acuerdo a las reglas del modelo de seguridad con el que se está trabajando), en particular, el creador del documento ha preferido mantenerlo aún de acceso restringido.

También puede haber una especificación en un sentido contrario: Aunque un documento de este tipo podría ser consultado solamente por su creador o sólo por la comunidad a la que éste pertenece, por ejemplo, el creador, ha decidido permitir su consulta pública por todos los usuarios.

Así pues, una cosa son las reglas generales y otra las específicas de una instancia de un tipo de documento, lo que al final determina qué se puede hacer con un documento en particular. La Arquitectura de información establece reglas, pero en el uso, a los documentos se les da la palabra.

viernes, 14 de septiembre de 2012

El contexto del ingreso y la modificación de documentos y la seguridad informacional

La edición de contenidos o documentos se realiza en contextos.
Los contextos tiene implicaciones funcionales y de seguridad.

Llevamos varias semanas hablando de la seguridad informacional. Un tema fundamental en la prestación de servicios y que como hemos estado viendo nos conduce a la necesidad de tener modelos de seguridad: representaciones de cómo nos interesa manejar el acceso y lo que se puede hacer con un documento o una funcionalidad a la que nos aproximamos digitalmente. Muchas veces al hablar de acceso a documentos la gente se refiere (implícita o explícitamente) sólo a la consulta. Pero el acceso a documentos es mucho más complejo que la mera consulta. Por un lado está la edición de documentos y, por otro, siguiendo en profundidad, los contextos en que se realiza la edición. Hoy queremos llegar a entender cómo es que se trabaja el tema de la seguridad en los contextos en que se realiza la edición de documentos. Eso nos llevará, por cierto, a la necesidad de ciertas definiciones adicionales.

Para empezar, recordemos que tenemos que distinguir la posibilidad de consultar un contenido de información de la posibilidad de editarlo. Y descomponiendo la edición, vemos que una cosa es la posibilidad de modificar un contenido y otra es la de eliminarlo o de agregar nuevos registros. Por eso en un esquema completo de permisos no se trata de definir si tenemos acceso o no a un tipo de documento (lo que resultaría demasiado general), sino qué es lo que podemos hacer sobre ese tipo de contenido o documento: consultar, insertar, modificar o eliminar.

Todavía podemos sofisticar los diseños de los modelos cuando pensamos que los ingresos a ciertos tipos de contenidos de información o documentos se hacen en situaciones dadas y eso significa que en algunos casos necesitamos poder ingresar un conjunto de campos (metadatos, variables) y en otros requerimos poder ingresar otro conjunto de campos.

Con la modificación también podemos sofisticar los diseños de los modelos cuando analizamos que al considerar la modificación de ciertos tipos de documentos podemos (o debemos) distinguir contextos donde debemos poder modificar un conjunto de campos y situaciones en las que debemos poder modificar otro conjunto de ellos.

Esa noción de contexto o de situación en la que se realiza un ingreso de un documento o la modificación de los mismos nos conduce a la necesidad de introducir dos nuevas categorías que debe manejar el Arquitecto de Información. Estas categorías son particularmente útiles cuando se está entendiendo un problema de gestión, conversando con el responsable de un servicio informacional o modelando una solución: se trata de los servicios de ingreso y los servicios de modificación.

En efecto, un servicio, bien sea de ingreso o de modificación es un esquema que representa una situación o contexto de edición y que define las variables (campos o metadatos) que pueden modificarse, el orden, las características funcionales que eventualmente deben manejarse para cada variable y finalmente, el aspecto de la seguridad, para qué comunidades de usuarios es válido este servicio de edición, este contexto de trabajo que estamos definiendo.

Metodológicamente la recomendación es concentrarse en la funcionalidad del servicio y en el momento de trabajar con las comunidades y la seguridad, analizar si el servicio puede trabajar en términos de las definiciones generales de los perfiles de seguridad o hay que incluirle restricciones o consideraciones adicionales o específicas.

viernes, 7 de septiembre de 2012

Más sobre modelos de seguridad con múltiples comunidades


Lo que un usuario que pertenece a varias comunidades puede o
no hacer depende de como se interpretan las consecuencias de
pertenecer a varias comunidades
La semana pasada estuvimos analizando como se modela la seguridad informacional para manejar casos en los que las personas hacen vida dentro de varias comunidades. En estos casos no es suficiente la definición detallada del perfil de lo que pueden o no hacer los miembros de las distintas comunidades de usuarios sobre cada tipo de documentos para decidir lo que alguien puede o no hacer.

Vimos que no hay una solución única y que hay cuatro modelos principales: Permisos individuales, Permisos de grupos, Permisos de unión de grupos y Permisos de intersección de grupos. Por razones de espacio explicamos sólo los dos primeros y dejamos para esta oportunidad los dos últimos.

Tanto el Modelo de unión de grupos como el Modelo de intersección de grupos comparten la facilidad de uso de que la persona está siempre conectada como persona y no como uno de sus roles. La diferencia está en la respuesta a qué se considera que es la conexión de una persona como persona con múltiples perfiles. Veamos los detalles:

Modelo de Permisos de unión de grupos: Bajo este modelo se considera que lo que una persona puede hacer es la suma de lo que puede hacer con cada uno de sus perfiles.

Si alguien con un perfil A no puede acceder a un tipo de objeto X pero con un perfil B, que corresponde a una comunidad a la que también pertenece, si puede, finalmente el sistema le permitirá acceder el objeto X.

Bajo este modelo se enfatiza la unicidad de las personas y el poder de hacer. La persona no está conectada bajo un rol, como en el caso del Modelo de Permisos por grupos, sino con todos sus roles, con todas sus comunidades y esto significa, en términos prácticos, sumando todos las posibilidades y nunca restando de estas las restricciones. Es decir, los perfiles se usan para aumentar permisos o posibilidades.

Modelo de Permisos de intersección de grupos: Bajo este modelo se considera que lo que una persona puede hacer en cada momento debe ser lo menos permisivo de lo que puede hacer con cada uno de sus perfiles.

Si con un perfil A no puede acceder a un tipo de objeto X, el sistema finalmente no le permitirá acceder el objeto X aunque con un perfil B, asociado a una comunidad a la que la persona también pertenece si se puede. Esto porque ya hay por lo menos uno de sus perfiles (el A en este caso) que lo restringe.

Bajo este modelo también se enfatiza la unicidad de la persona pero, a diferencia del caso anterior, de sus perfiles se resalta lo no se debe poder hacer. En cambio, de manera similar al caso anterior, también se considera que la persona no está conectada bajo un rol, como en el caso del Modelo de Permisos de grupo, sino con todos sus roles, con todas sus comunidades. El punto clave está en que esto significa, en términos prácticos, sumando todas sus restricciones y nunca aumentando las posibilidades. Es decir, los perfiles se usan para aumentar limitaciones.

Es posible encontrar situaciones en los que uno de estos modelos se considere más apropiado pero siempre habrá otras en las que no. Los dos modelos que examinamos de hoy tienen la ventaja de su sencillez en el sentido de que la persona no tiene que declarar su rol, pero por otro lado, son más limitados porque a veces una persona quisiera tener la perspectiva de prescindir de uno de sus roles, por ejemplo, para evitar borrar algo por accidente o para poder hacer algo un poco más exigente, pero esto no puede hacerse con los modelos que vimos hoy.

viernes, 31 de agosto de 2012

Seguridad informacional cuando se tienen varios perfiles

Muchas personas tienen varios perfiles. Esto hay que tomarlo en cuenta
cuando se diseña la seguridad de una solución de gestión de información.
(Imagen tomada de  http://www.freepik.es)

La semana pasada introdujimos el concepto de Modelos de seguridad. Fue en el contexto de la conversación de seguridad informacional desde la perspectiva de las conversaciones entre el Gerente de servicios de información y el Arquitecto de información. Vimos que, como habíamos estado conversando en las semanas anteriores, la seguridad se maneja en los servicios modernos a través de perfiles que se les asignan a cada una de las comunidades de usuarios con las que se trabaja. El problema se complica cuando caemos en cuenta que muchas personas no tienen un único perfil, sino varios. No pertenecen a una única comunidad, sino a varias. Eso nos lleva a hacernos la pregunta de ¿cómo afecta la pertenencia a múltiples perfiles a nuestros modelos de seguridad informacional?

El hecho de que una persona pertenezca a varias comunidades y por tanto tenga varios perfiles se toma en cuenta en Arquitectura de Información entendiendo que existen cuatro modelos a seguir: Permisos individuales, Permisos de grupo, Permisos de unión de grupos y Permisos de intersección de grupos. No hay una solución única. Es un problema que tiene que ver con el cómo nos parece que representamos mejor la solución al problema de gestión de información sobre el que trabajamos y por supuesto, con la posibilidad de establecer el modelo diseñado con las herramientas que usamos para modelar nuestra particular Arquitectura de información.

Describimos brevemente a continuación los dos primeros modelos mencionados y dejamos para la siguiente oportunidad los otros dos:

Modelo de Permisos individuales: Consiste en definir para cada persona, individualmente, lo que puede hacer y lo que no puede hacer con el sistema que desarrollamos. Como hemos visto este modelo es poco aconsejable, a no ser que el número de personas sea menor que diez ya que, como explicamos en su oportunidad (ver Una persona no es un perfil: Todos tenemos varios perfiles), los sistemas son entes vivos, las condiciones cambian y resulta completamente impráctico tener que recorrer perfiles, persona por persona, cada vez que ocurre un cambio como, por ejemplo, la incorporación de un nuevo tipo de documento o de funcionalidad.

Modelo de Permisos de grupo: Consiste en establecer como norma que aunque cada persona tiene varios perfiles o pertenece a varias comunidades, en un momento dado, o, en un espacio de interacción dado, sólo está activo en una de ellas y por eso siempre se está claro bajo que perfil está conectado. Este perfil de conexión determina lo que puede y lo que no puede hacer en esas circunstancias.

Este modelo suele ser recomendable en una gran cantidad de situaciones, es bastante sencillo de operar y hace fácil a las personas estar consciente de sus distintos roles y perfiles organizacionales. La ventaja y desventaja para la persona es que, aunque pertenezca a varias comunidades, es explícito siempre bajo cual de ellas se está conectado porque se considera que, en un instante dado, se trabaja bajo un único y explícito rol, seleccionado por la persona entre sus múltiples perfiles. Por supuesto, la funcionalidad debe permitir cambiar este rol en cualquier momento y debe hacerlo visible en la pantalla para evitar equívocos.

Una de las ventajas de esta aproximación está en el poder que da a la persona de controlar su actividad y de asumir distintas perspectivas de trabajo. Así por ejemplo, la persona puede, en un momento dado, quitarse permisos temporalmente para trabajar en forma más segura. También puede adoptar un rol y ver lo que ven los miembros de una cierta comunidad a la que se pertenece, independientemente de que se pertenezca a otras con más o menos atribuciones.

viernes, 24 de agosto de 2012

Una persona no es un perfil: Todos tenemos varios perfiles

En la imagen, simultáneamente, el rostro de una mujer o una mariposa
que visita una flor. Los arquitectos de información modelan la realidad.
Pero un modelo es siempre una representación. Por lo que ante la
misma realidad pueden haber varios modelos válidos.
Hemos estado hablando de seguridad y de las distintas perspectivas con las que podemos entrarle al tema. Precisamente la semana pasada describimos por qué la seguridad informacional se trabaja, en forma práctica, a través de perfiles y no como un conjunto de permisos que tienen personas individuales. Queremos ahondar esta semana en más detalles sobre éste punto. Cuando una persona está en varias comunidades o cuando cumple varios roles en una organización, tiene varios perfiles. ¿Cómo manejamos lo que puede o lo que no puede acceder y hacer en un sistema? Es un tema de interés central para los directores de servicios de información y nos lleva a la necesidad de introducir el concepto de modelos de seguridad.
En primer lugar es importante tomar en cuenta que el Arquitecto de Información diseña soluciones de gestión que funcionen en un cierto ambiente de uso (el público en general, un conjunto de comunidades, una organización, etc). Una solución implica un modelo de información que debe tener la virtud de representar razonablemente la realidad del problema de gestión que se desea resolver, al tiempo que es lo suficientemente sencillo como para que pueda usarse en términos prácticos.
Precisamente la semana pasada (Seguridad informacional: ¿Por qué perfiles y no manejo de usuarios individuales?) vimos como suele ser imposible atender los requerimientos de seguridad de cualquier organización gestionando el control de lo que cada una de las personas, individualmente, puede hacer o no puede hacer, en cada caso, con cada situación, con cada tipo de objeto. Por eso se usan perfiles, es decir, abstracciones de lo que un grupo de personas con características comunes pueden hacer. Como las personas las agrupamos en Comunidades es natural que a cada comunidad le asociemos un perfil. Esto nos permite ser prácticos. Definimos lo que un conjunto de individuos puede hacer manejando perfiles de comunidades y no persona por persona. Hasta allí todo está bien, el problema es que en la realidad las personas suelen tener varios roles o pertenecer a varias comunidades y, en ocasiones, pueden querer o necesitar cambiar temporalmente sus roles o perfiles.
¿Cómo la gestión de la seguridad informacional toma en cuenta esto? ¿Qué permisos debe tener una persona que tiene varios roles o que pertenece a varias comunidades? Como veremos no hay una respuesta única, sino que se trabaja con el concepto de modelos de seguridad. A veces en forma implícita, a veces en forma explícita.
Existen, de entrada, cuatro modelos de seguridad simples de entender:
  1. Permisos individuales, por persona.
  2. Permisos de grupo, atendiendo uno solo de los roles escogido por el usuario, entre todos sus perfiles.
  3. Permisos de unión de grupos, sumando todos los permisos que tienen todos los roles de un usuario.
  4. Permisos de intersección de grupos, sumando todas las restricciones de todos los roles de un usuario.
El primero de estos modelos no es muy conveniente y lo analizamos la semana pasada. En las restantes soluciones hay ventajas y desventajas asociadas, que conviene examinar con más detalles y las analizaremos en nuestro próximo post.

viernes, 17 de agosto de 2012

Seguridad informacional: ¿Por qué perfiles y no manejo de usuarios individuales?


La seguridad informacional se administra bien cuando se establecen
perfiles para cada comunidad de usuarios y para cada tipo de documentos
Llevamos varias semanas con el tema de la seguridad informacional. Hemos hecho la observación de que hay varias perspectivas complementarias en la conversación de seguridad, algunas de ellas más cercanas a los temas duros de la ingeniería y otras más vinculadas con el tema de la gestión de contenidos y de servicios. Todas ellas son muy importantes para el gerente de servicios de información o el desarrollador de aplicaciones. Hoy queremos trabajar un poco con la relación entre la gestión de perfiles de comunidades de usuarios y la seguridad, un punto clave en Arquitectura de información.

Es claro para todo el que ha administrado un servicio de información que siempre hay que gestionar la seguridad y, como vimos en nuestro último post (Ver), la conversación no se acaba cuando hablamos de disponibilidad, confidencialidad e integridad.

Hay un punto muy importante y es acceso. En un servicio en funcionamiento, cada persona tiene que tener la posibilidad de acceder a los contenidos que requiere y a la funcionalidad que necesita para manejar esos contenidos. Quizá consultar cierta información es suficiente, pero en muchas ocasiones se requiere la posibilidad de modificar los contenidos, crearlos e, incluso, eliminarlos. También hay que considerar otras funciones: diseminación, validación, autorizaciones, etc.

Una manera de manejar estas operaciones puede ser el darle, a través de un sistema, autorizaciones a cada persona para marcar lo que ésta puede o no puede hacer. Precisamente allí está el punto que queremos señalar hoy. En términos informáticos este control por persona es posible y puede hacerse muy minuciosamente. Sin embargo es completamente desaconsejado. Ningún Arquitecto de Información lo recomendaría. ¿Por qué?

La razón es que este esquema de controlar lo que una persona individualmente puede hacer no escala, no permite crecimiento y por eso choca con una parte crucial de lo que el Arquitecto de Información debe estar siempre pendiente: la escalabilidad del servicio. Suena perfecto, minucioso y hasta meritorio establecer lo que una persona pueda realizar con cada funcionalidad del sistema. Sin embargo, un sistema así no es administrable.

En la práctica los sistemas son entes vivos que tienen una dinámica que cambia y en la vida institucional el rol de las personas dentro de las organizaciones suele cambiar también. Cuando alguien se va de vacaciones o se enferma, por ejemplo, puede haber un movimiento temporal de roles. Es demasiado complicado que cuando se incorporen nuevas funcionalidades, o cuando se cambien temporal o en forma permanente procesos previamente establecidos, haya que tener que recorrerse, persona por persona, la lista de usuarios, para ajustar lo que cada una puede hacer o lo que cada una no puede hacer. Si el sistema fuera algo usado por una decena de personas quizá podría funcionar, pero en la práctica, incluso con una pocas decenas de personas es inmanejable el tema del control de la funcionalidad y de la seguridad si no tenemos comunidades y perfiles asociados a ellas. Estos perfiles los usamos para controlar lo que cada quien tiene acceso como contenido y como funcionalidad. La experiencia señala que lo que cada quien puede hacer con la información a la que tiene acceso depende de las comunidades a las que pertenece.

Este tipo de gestión de la seguridad por comunidades de usuarios permite administrar sistemas reales donde los cambios están a la orden del día.

A veces se argumenta que una persona es muy especial y que ella tiene que poder hacer, individualmente, algo que no está en ningún perfil. Esta argumentación es insostenible. No suele ser cierta, pero incluso si lo fuera, lo que estamos definiendo es un rol y por tanto un perfil de una comunidad en la que, aparentemente, hoy hay sólo una persona, cosa que, por cierto, siempre recomendamos revisar.

viernes, 10 de agosto de 2012

Confidencialidad, Disponibilidad e Integridad: ¿Qué falta en la conversación?

Dentro de una comunidad puede haber difusión de contenidos, mientras
que desde fuera de la comunidad no hay ningún tipo de acceso
(imagen desde  http://icetechnologies.com)

Con estas tres palabras, Confidencialidad, Disponibilidad e Integridad, muchas veces se resume el tema de la seguridad informacional. Pero, como observamos la semana pasada, la seguridad es una conversación que tiene perspectivas diferentes según se aborde desde la Arquitectura de Información o desde la Ingeniería Informática. Una orientación no es mejor que la otra, son enfoques diferentes y complementarios. Hoy continuaremos aportando algunas distinciones adicionales, procurando siempre mantener un lenguaje asequible tanto a directores de servicios de información como a desarrolladores de aplicaciones.

Retomemos la conversación desde los tres puntos claves en los que el Arquitecto de Información se centra, antes que nada, cuando trabaja el tema de seguridad:

1) Todo el que tiene que tener acceso a ciertos contenidos, debe tenerlos.
2) La funcionalidad debe permitir la operación segura, estable, de los sistemas de información y sus reglas.
3) En todo momento, la información debe mantener su integridad, como información.

Como al primero de estos puntos ya nos referimos (Ver Seguridad informacional bajo la perspectiva del Arquitecto de Información), trabajaremos hoy con los dos últimos:

La Arquitectura de información debe garantizar que la funcionalidad permita la operación segura, estable, de los sistemas de información y sus reglas. Cada quien no sólo debe tener acceso a ciertos contenidos de la base de información (punto uno), sino que debe poder hacer con ellos lo que se espera que pueda hacer. En esa dinámica de uso cotidiano, los contenidos crecen y se desarrollan, mientras la información debe mantener la coherencia, la estructura, la practicidad, la integridad con la que fueron definidas las reglas iniciales. Para un novel esto es algo que se da por hecho, sin embargo, en las dinámicas que impone el uso pueden haber degradaciones en la consistencia de la información o en las premisas que se hicieron cuando se construyó un sistema. De allí que lo sano sea, entre otras cosas, una cierta labor de medición y seguimiento de esta coherencia informacional y esto debe incluirse en las conversaciones y las actividades.

En el tercer punto se toca el aspecto de la Integridad. Hay que señalar que aunque en la literatura (y numerosas páginas de la Internet) se habla de ella, la conversación muchas veces se realiza dentro de marcos excesivamente tecnológicos que dejan de lado aspectos importantes de la gestión de información: En concreto, hay que distinguir lo que puede ser integridad de datos, que garantizan los informáticos en sus contextos y con sus herramientas, de la integridad de información con la que trabajan los Arquitectos de Información.

La conversación es interesante, porque puede haber integridad de datos sin que haya integridad en la información: Si se rompió la conexión entre uno de los títulos de un documento, o entre un cierto dato y el objeto de información al que pertenece, por ejemplo, lo más probable es que las revisiones de integridad de bases de datos señalen que éstas están correctas, pero las revisiones de integridad de información señalen las faltas.

El punto es que para el usuario final, la pérdida de integridad de información puede ser tan nefasta como la pérdida de integridad física de los dispositivos que la contienen.

Reuniendo los comentarios de la semana pasada (ver) con los de ésta podemos notar que aunque en muchos discursos se establece que la Seguridad de información tiene que ver con tres aspectos básicos: Confidencialidad, Disponibilidad e Integridad, en la práctica la discusión que se hace es, en demasiadas ocasiones, menos útil de lo que debería porque no se comprenden o no se abordan las diferencias y complementos entre los enfoques de la Informática y de la Arquitectura de información. En nuestra experiencia, si no se conversa adicionalmente sobre Acceso, Comunidades y Objetos de información y sobre Funcionalidad e Integridad dinámica de información se dejan por fuera aspectos que son claves para las organizaciones. En otras palabras, siempre hay que tener en cuenta que el estudio de la seguridad informacional tiene perspectivas y contextos.

viernes, 3 de agosto de 2012

Seguridad informacional bajo la perspectiva del Arquitecto de Información


En cada problema de desarrollo de espacios que requieren de construcción civil
funcional, las perspectivas del Ingeniero y del Arquitecto son complementarias.
Analogías existen en servicios de información (foto:  http://www.velavke.co.za  )
La semana pasada vimos que la Seguridad informacional tiene muchas aristas y mencionamos algunas de ellas, señalando en la conversación que el tema cambia de forma significativa los puntos claves y el lenguaje con el que se debe manejar según la perspectiva funcional que tomemos y que, por eso, siempre hay que aclarar de qué seguridad estamos hablando. Como veremos hoy, la aproximación a la seguridad en Arquitectura de Información resulta natural en las conversaciones cotidianas de los gerentes de servicios de información y por eso para los desarrolladores de soluciones y responsables de servicios resulta conveniente manejar las distinciones que exponemos a continuación.

Mucha de la literatura que leemos en la Internet no lo aclara, pero hay abordajes de Seguridad informacional que son más propios de Ingeniería informática y aproximaciones que están más ligadas a la Arquitectura de Información. Quizá con los primeros enfoques colocamos pilares para los segundos, pero la relación es de complementariedad y no de jerarquía.

Muy en concreto, la semana pasada mencionamos tres puntos críticos conversación de seguridad con el Arquitecto de Información: 1) Todo el que tiene que tener acceso a ciertos contenidos, debe tenerlos. 2) La funcionalidad debe permitir la operación segura, estable, de los sistemas de información y sus reglas. 3) La información debe mantener su integridad, como información. Comentemos:

En relación al primer punto, se dice fácil que hay asegurar todo el que tiene que tener acceso a ciertos contenidos lo tenga. Pero hay detalles que están vinculados con lo que se llama disponibilidad lógica y observaciones que hay que hacer sobre la confidencialidad. Veamos:

El acceso a los contenidos mencionado arriba requiere de la disponibilidad, e implica, desde luego, en la misma afirmación, un lado prohibitivo complementario: que no se tenga acceso a lo que no se debe tener, que ciertos contenidos luzcan como no disponibles. De allí que la disponibilidad lógica que ocupa al Arquitecto de Información no es la física que ocupa al Ingeniero de infraestructura. Es decir, no se trata de que los equipos estén encendidos, operacionales y las bases de datos estén trabajando. Eso es seguridad física. Antes bien el punto para el Arquitecto de información es que los contenidos deben estar accesibles según ciertas reglas establecidas institucionalmente para las comunidades involucradas en cada caso.

En relación a la confidencialidad, es importante entender algunas complejidades adicionales, propias del quehacer cotidiano institucional. En una organización las personas son miembros de equipos (comunidades, instancias organizativas) que comparten información: confidencialidad significa que desde afuera de una comunidad no se debe tener acceso a ciertos contenidos, pero hay que observar que internamente, dentro de la comunidad, puede haber hasta difusión. Este detalle hay que examinarlo en el contexto de cada tipo de contenido y cada comunidad involucrada o no con él. Como las propiedades son además dinámicas (varían en el tiempo) y como las personas pueden ser miembros de varias comunidades, se requiere de herramientas para manejar contenidos o bases de información. No son suficientes las herramientas básicas que proporcionan las bases de datos.

En nuestro próximo post comentaremos sobre los puntos dos y tres mencionados arriba y aportaremos algunas distinciones sobre seguridad informacional que son importantes tener claro cuando uno participa en equipos que desarrollan soluciones de gestión de información o cuando se es responsable de servicios.

viernes, 27 de julio de 2012

¿De que seguridad de información estamos hablando?



Los virus y los ataques de hackers no son el problema
para el Arquitecto de Información. La Seguridad informacional
tiene para el Arquitecto visibilidad desde otra perspectiva
La semana pasada, tocamos el tema de la seguridad informacional al hablar de la cuarta dimensión del trabajo de los Arquitectos de Información. En efecto, estos profesionales definen perfiles de usuarios que implementan como comunidades en los sitios Web que desarrollan y, como mencionamos en esa oportunidad, al hablar de comunidades surge necesariamente el tema de la seguridad del acceso a la información. Algunos objetos de información son compartidos por algunas comunidades, mientras que otros son específicos de lo que se hace internamente dentro de cada una de ellas. Cuando se entra en el tema se descubre que hay muchos detalles y aristas que se deben tomar en cuenta cuando se habla de seguridad en información, al punto de que más de una vez es pertinente hacernos la pregunta que aparece en el título de este post: ¿De que seguridad estamos hablando?

Para empezar, es conveniente aquí saber que el tema muy actual de los virus informáticos que destruyen contenidos de información y sistemas normalmente no es el punto que les quita al sueño a los Arquitectos de información. Los virus informáticos son un mal de la sociedad contemporánea, pero los departamentos de informática de las instituciones normalmente saben qué hacer: una combinación de normas y formación de sus usuarios, con el uso de adecuadas herramientas antivirus. Los virus (informáticos y biológicos) seguirán existiendo y los respectivos especialistas encargándose de ellos para que los demás hagamos nuestro trabajo.

Tampoco los Arquitectos de Información se ocupan de los hackers y el acceso malintencionado a los sistemas corporativos. Es sabido que actualmente hay personas que combinan una gran inteligencia y formación con la ausencia de ética y que, en ese crisol, usan su talento para divertirse penetrando las redes corporativas de importantes instituciones con el objeto de deleitar a su ego, causar problemas económicos, políticos, operacionales, etc., u obtener ciertos beneficios, para ellos o para alguien. Pero el trabajo de lidiar con este tipo de ataques es tarea de otro tipo de especialistas, los responsables de seguridad informática, más que de los Arquitectos de información.

Los Arquitectos de Información trabajan sobre la base de que la infraestructura informática de la institución funciona, está operativa, bien implementada, libre de virus y aislada del ataque de hackers malintencionados. Su trabajo en cambio se orienta a crear condiciones de seguridad, a partir de allí, para las aplicaciones y los servicios que descansan en ellas. Se ocupan de varias e importantes vertientes de la seguridad informacional.

Sus temas de conversación no son los de la seguridad con la que lidian los ingenieros y que tiene que ver con las tecnologías informáticas. Sino aspectos básicos del manejo de información por comunidades. Qué implicaciones (más allá de las informáticas) tiene el querer garantizar aspectos como los de estas tres simples formulaciones:


    1   Todo el que tiene que tener acceso a ciertos contenidos, debe tenerlo.
    2   La funcionalidad debe permitir permite la operación segura, estable, de los sistemas de información
         y sus reglas.
    3   La información debe mantener su integridad, como información.

La semana que viene veremos detalles sobre estos puntos, profundizando un poco en la conversación de seguridad desde la perspectiva de la Arquitectura de información.




viernes, 20 de julio de 2012

Seguridad: También en la cuarta dimensión de la Arquitectura de Información



Cada tipo de usuario tiene normalmente acceso a ciertos tipos de objetos
de información que les permite realizar ciertas funciones...
La semana pasada entramos en la conversación de la cuarta dimensión de la Arquitectura de Información: Comunidades y Seguridad. Las restantes dimensiones en las que trabaja el Arquitecto de información las hemos cubierto en otras oportunidades: Estructura, Funcionalidad, Navegación e Imagen. Dado que por razones de espacio no pudimos entrar en el tema de la relación de los aspectos ligados a la seguridad en el trabajo con comunidades de usuarios, dejamos hasta este post la realización de la conversación sobre el acceso a información y los permisos vinculados a tipos de usuarios y roles, algo en lo que todo gerente y todo arquitecto de información tiene que tener claridad conceptual y capacidad para participar en el diálogo interdisciplinario.

La seguridad es tema obligatorio cuando se trabaja con comunidades, porque es implícita en la definición de lo que éstas son. Pero la seguridad tiene varias vertientes.

La primera es el acceso al sitio Web y los documentos o tipos de documentos que los miembros de cada perfil de usuarios deben poder manejar. Esto sería muy bueno que estuviera claramente definido en la herramienta que finalmente se use para la implantación del sitio Web, porque de otra forma la evolución natural, necesaria e inevitable, que tenga el servicio con el que trabajamos terminará haciéndolo un poco complicado de implementar. Siempre hay cambios en el desarrollo de un sitio Web derivados de su crecimiento en usuarios o en servicios y estos cambios siempre plantean consideraciones en lo que respecta a la seguridad. Por eso es que más que un manejador de base de datos (donde sólo podemos manejar seguridad de datos) se requiere un manejador de contenidos o de bases de información, donde podemos manejarla seguridad en términos de perfiles de usuarios y tipos de contenidos.

Además del acceso por tipo de documento o de objeto de información que los miembros de una comunidad de usuarios puedan tener, está el acceso funcional. No se trata sólo del problema binario de qué tipo de contenido una determinada comunidad puede consultar, sino del problema de definición más compleja de qué funciones son las que pueden realizar los miembros de cada comunidad sobre cada tipo de documento: añadir contenidos, modificarlos, borrarlos o meramente consultarlos.

Pero los documentos tienen atributos, subpartes, campos, lo que significa tener que determinar cómo es que este manejo interno se trabaja en cada comunidad. Por ejemplo, pudiera ser razonable que la operación sobre los atributos internos de una estructura informacional se resolviera en forma muy sencilla, a nivel de cada tipo de documento, como un todo, pero lamentablemente no siempre ocurre así. Hay casos en los que la necesidad particular de procesamiento es un poco más sofisticada y sólo algunos campos deben ser accesibles en la consulta o edición por algunas comunidades.

Lo interesante es que la seguridad pueda especificarse en forma simple, cada vez que no se requiera más, pero que pueda definirse en forma elaborada, cuando se requiera satisfacer requisitos más sofisticados. Volveremos sobre estos temas. Extrañamente, la literatura sobre Arquitectura de Información suele hablar poco del tema de seguridad, pero aún en los sitios más abiertos y públicos, la seguridad es una condición sobre la que hay que trabajar y donde el diablo puede andar en los detalles.