Arquitectura Drupal ~ Una visión arquitectónica

¿ Cómo conseguir una batería de portales ? ¿ Realmente creen que de un portal a otro hay tantas diferencias ?

La realidad es que no, sus similitudes rara vez bajan del 90% de los componentes comunes utilizados.

Por ello, la necesidad de preparar una arquitectura de componentes que permita una fácil re utilización.

Esta arquitectura requiere un completo sistema documental, para facilitar su identificación y diagnosticar de forma más adecuada la satisfacción de requisitos.

Estas relaciones se deben hacer por funcionalidad común.

Drupal nos facilita la labor, pues ya propone su propio sistema de relaciones entre módulos, pero nosotros debemos continuar esa misma labor organizando otros muchos componentes que vamos creando.

Para sentar una base inicial, indicaremos la subdivisión propuesta por Drupal.

Se ha especificado una lista de las funcionalidades más comunes en la mayoría de los portales :

- Autenticación

- Presentación de contenidos

- Comunidades

- Gestión de Usuarios

- Correo - Listas - Foros

- Publicidad - PopUps

- Localización

- Búsquedas

- Sindicación

La propia comunidad Drupal estructura aún así sus módulos en una serie completa de funcionalidades que se suman a las más comunes. Se indican a continuación:

- Utilidades

- Gestión de contenido

- Administración

- Tipos de contenido

- Desarrollo

- Comunidad

- Media

- E-Commerce

- Filtros - Formato de entrada

- Vistas

- Categorías

- Movilidad

- Utilidades Javascript

- Navegación

- Gestión de Ficheros

- Backups - Importación - Exportación

- Paginación

- Seguridad

- Prevención de Spam

- Evaluación - votaciones

- Localización - Idiomas

- Grupos Orgánicos

- Estadísticas

- Eventos y Workflows

- Rendimiento

- Juegos

- RDF - Formatos

- Gestión de Rutas

Es una base para poder organizar una estructura de componentes consistente y con una sencilla re utilización.

La capacidad de satisfacer los requisitos no depende de un sólo producto ni de un único desarrollo.

Es la filosofía libre, nuestro éxito está intrínsecamente ligado al de los componentes que utilizamos. Entre todos crecemos para mejorar la calidad y es esa calidad la que nos permite triunfar y indirectamente mejorar las aplicaciones disponibles para la sociedad.

Por tanto, mejoramos la sociedad.

Y es que en cuanto a proyectos de mala calidad el software ha sido un claro ejemplo, pues cualquiera se ponía a programar, a intentar sacar el trabajo, como se llama en mi país, sin importar la arquitectura, la robustez, la seguridad, el único objetivo es que funcione.

Ha sido ese uno de los pilares del fracaso del software corporativo.

En Drupal en particular y en el Software libre en general NO ES ASÍ. O no debe ser, pues aún he discutido este tema con mucha gente que no es capaz de ver que los desarrolladores o arquitectos de software deben ser perfiles altos y especializados y familiarizados con el producto.

Por tanto esos cambios deberían solicitarse a los perfiles más acordes para ello, que suelen ser los responsables de dicho módulo o tema y que el cambio solicitado enriquezca el producto.

Esta debe ser la linea de acción, y en esta linea, el incrementar o mejorar la funcionalidad aportada por Drupal debe ser un aspecto trascendente a la hora de encarar los requisitos de un futuro proyecto.

Por tanto debemos considerar que es más importante compartir capacidades con otros productos y entre todos buscar un ideal común para disponer de una aplicación más robusta que intentar hacer la guerra cada uno por su cuenta.

Entre todos debemos hacer que el producto sea cada vez mejor y eso implica que todos los componentes y empresas que participan en él también vayan siendo cada vez mejores.

Es por ello que Drupal quiere que Varnish sea cada vez mejor, que Memcached incremente su eficiencia.

Que Apache, Ngnix, Ligthttp seán cada vez más rápidos.

Que mysql sea más eficiente.

Que php vaya mejorando día a día.

Esa es la filosofía libre. Una apuesta por la calidad.

Hablamos de usabilidad como conjunto de técnicas que simplifican el manejo de una web y la acercan a las necesidades de los usuarios o clientes.

La capacidad para encapsular un producto como Drupal en un conjunto de abstracciones que simplifiquen el modelo ya acerquen el resultado al negocio del cliente es arquitectura.

Por defecto, un usuario jamás debería adivinar que es Drupal el producto que hay tras su site.

Por tanto es importante gestionar adecuadamente los roles del portal y asignar visibilidad en razón de las necesidades de cada rol.

Consideramos necesarios los siguientes 4 roles :

- Administrador : Conocedor de Drupal. Tiene permiso para hacer cualquier acción en el portal.

- Supervisor : Conocedor del Negocio. Debe poder realizar cualesquiera acciones que manejen el negocio. No necesita tener conocimiento alguno de Drupal.

- Usuario autenticado : Permiso para modificar , insertar y eliminar algunas facetas del negocio

- Usuario anónimo : Cualquier visitante del portal

Estos roles se podrán incrementar en razón de las necesidades del site.

El papel de cada rol juega un factor determinante en la seguridad del site.

El administrador deberá constatar todos los nuevos parches de seguridad que se puedan aplicar con objeto de intentar que las medidas de seguridad aplicadas sean las adecuadas.

El arquitecto del sistema debe definir adecuadamente las acciones a realizar en razón del rol de cada acción , cerciorándose de respetar criterios de privacidad del negocio.

En razón a la usabilidad, en Brqx Group, disponemos de dos metodologías de diseño aplicables :

Light Potals - Portales ligeros

El objetivo de dicha metodología es minimizar las opciones disponibles ajustándolas a las necesarias.

A su vez aplicamos la metodología Liquid Potals - Portales ágiles

Su fundamento es disponer de la máxima cantidad de información sin necesidad de usar scrolling de pantalla. La filosofía es que todas las acciones estén a vista del usuario, dar agilidad a los movimientos como si fuera un líquido.

Estas metodologías están a disposición de una adecuada arquitectura que desee apostar por la sencillez y la facilidad de manejo de un site.

A su vez un arquitecto debería intentar fomentar un sistema orto normal de forma que en todos los portales, los procedimientos de actuación sean similares.

Sin duda la vida de un site no debe considerarse hasta su creación, sino que más bien, ese debería ser el principio.

La capacidad de incrementar funcionalidad sin apenas coste adicional es una de las grandes bazas del software libre y por supuesto de la robustez de un producto como Drupal.

Por tanto cualesquiera nuevas funcionalidades aportadas por componentes ya utilizados pueden suponer un incremento de funcionalidad agradecida para la mayoría de portales que se están manteniendo.

Es por ello que un site no debe considerarse como un portal único, sino como todo un proyecto.

Un proyecto con vida, que dispone siempre de entornos paralelos.

En razón a esta funcionalidad disponemos de otras dos metodologías.

La primera es Live Backups - Copias de Seguridad Vivas.

Está enfocada en aportar esa sensación de continuidad a los sites, con capacidad de poder visualizar el futuro y el pasado.

Sensación de control absoluto de la evolución de los portales.

Disponemos a su vez de varios proyectos de control, el primero de ellos pretende gestionar todos los portales y dominios :

Control Arquitectura Portales - Brqx

El otro portal pretende auto comprobar el funcionamiento de todos los sites, con objeto de poder anticiparnos a los problemas.

Control Servidores y Sites - Brqx NG

Esta filosofía encaja perfectamente con la metodología 5 Entornos - Five Environments

Donde se puede comprobar la evolución y el estado de cualquiera de nuestros portales.

Son múltiples técnicas que permiten simplificar la gestión y optimizar el desarrollo, con finalidad absoluta en criterios de calidad y en un acercamiento a las necesidades reales de los clientes.

Cuando valoramos un proyecto, debemos considerar hasta que punto es importante uno de los requisitos.

La relación de esa necesidad provocada por el requisito y un supuesto componente que lo va a satisfacer es un aspecto arquitectónico muy importante para poder equilibrar el proceso de creación del site.

Puede haber ocasiones donde el componente cumplimenta perfectamente esas necesidades. Será importante llegar a comparar con los posibles candidatos que también llegan a cumplimentarlas.

Es el momento de analizar los componente ya creados o existentes para poder decidir si es necesario un nuevo componente en el sistema.

Y si llega ese caso, hay que analizar el coste de implementación en razón a la importancia de dicho requisito.

Por tanto no todas las necesidades son iguales y no siempre es la mejor opción llegar a intentar solventarlas.

Es muy necesario hacer un estudio de componentes existentes, su estado del arte actual y los cambios futuros que van a conllevar.

Puede ser la mejor opción un aplazamiento de esa funcionalidad antes de involucrarse en un desarrollo cuyos beneficios son dudosos.

Y si realmente es necesario, sin duda la opción nunca será hacer un desarrollo independiente, sino unirse a la comunidad, acercarse a los creadores de dichos componentes o al que realmente puede solventar la necesidad y o bien solicitar sus servicios o bien colaborar con el para conseguir que esa colaboración permita solucionar el requisito. Esta debe ser la linea de acción.

Esta ha sido la que ha hecho grande el software libre, la colaboración y es la que permite anticiparse a problemas de compatibilidad y la que engrandece el producto y lo enfoca en un sistema de calidad cuyo único fin es mejorar la propia sociedad.