EspañaInglaterraAlemaniaItaliaPortugalFranciaEspañaInglaterraAlemaniaItaliaPortugalFrancia

a0002

Las primeras veces que te acercas a Drupal, no consideras su estructura como un enclave importantísimo para poder gestionar múltiples portales.

Los propios creadores de Drupal incluso empiezan a orientarnos de las posibilidades y de la importancia de una buena arquitectura de ficheros.

El ver que es un grave error meter todo en "modules". La oportunidad de clasificar en "sites/all/modules" distintos enfoques y distintas agrupaciones de módulos.

Esa capacidad para discernir las necesidades comunes de las opciones específicas para uno u otro portal es arquitectura.

Es importante hacer un enfoque adecuado de los portales que queremos desplegar y es trascendente entender el enfoque libre y recomendado por Drupal, donde en vez de buscar una guerra individual, se apuesta por una compartición de conocimientos y responsabilidades en el desarrollo.

Lo que hemos denominado Metodologías Ágiles Colaborativas, donde tu éxito depende del éxito de otras empresas y retunda en el completo éxito del producto.

Siguiendo esta filosofía, la gestión de portales no debería ser un control de versiones, pues ya el propio producto dispone de su propio control de versiones.

Los cambios o mejoras deberían hacerse en consonancia y acuerdo con los propios responsables de esos módulos o temas. Es esta idea la que nos infunde Drupal, y además es la más adecuada para asegurar los criterios de calidad del software.

Por tanto podemos ver como estructura ideal una gestión de portales que no tiene por qué ser gestión de versiones.

En esta estructura tenemos una parte relacionada directamente con el producto como son las carpetas :

-"includes"

-"scripts"

-"profiles"

-"modules"

-"misc"

-"themes"

La misma podría ser una serie de "links simbólicos" que apuntan a la versión más moderna y estable del producto.

Por tanto delegamos parcialmente en files y de manera más general en sites la personalización del producto.

Dentro de files podemos plantear una estructura común con personalizaciones para documentos como iconos, logos e imágenes :

/files/

Esta ruta se puede parametrizar para conseguir un acoplamiento más optimo de componentes comunes.

En la otra linea, en sites tenemos la siguiente estructura ya aportada por Drupal

/sites/all/ --> Para todos los portales

/sites/default/ --> Configuración por defecto

Como bien dije esta estructura incrementa la complejidad del portal y no nos permite hacer un enfoque de simplicidad.

En dicha estructura tendríamos, por ejemplo tres sites :

sites/site1

sites/site2

sites/site2

sites/all

sites/default

Como se puede comprobar todo está dentro del mismo sites.

Nosotros preferimos ver el producto de forma más sencilla, donde toda la estructura siempre sea similar sea cual sea el site y donde los cambios de entorno sean totalmente transparentes a la estructura interna:

En nuestra visión tendremos :

sites/default --> Sólo configuración

sites/all --> Componentes comunes y personalizados

Esta estructura será común en todos los portales.

Otra de las características relevantes del software libre es su gran capacidad de cambio, de mejora, de nuevas funcionalidades.

Es tan variante esta filosofía que en un periodo corto de tiempo una buena solución se queda obsoleta.

Por tanto es trascendente para un arquitecto en Drupal estar siempre al día de nuevos componentes, de su adaptación a las versiones.

Conocer perfectamente el Update Status y el Upgrade Status de sus portales.

Anticiparse a los problemas y cuando hay que actuar, estar preparado para ello. Es importante probar nuevas funciones, probar contribuciones para el producto, informarse de las ventajas aportadas.

Examinar comparaciones de productos, analizar las funcionalidades nuevas aportadas para ser capaz de decidir si esa novedad es trascendente para una mejora del portal o simplemente es un código ampliado que no aporta nueva funcionalidad.

Drupal tiene más de 5000 módulos, actualmente 4 versiones en danza, más de 500 contribuciones, multitud de información. Todo ello hace al producto completo y complejo.

Hay mil variantes y muchas formas distintas de hacer las cosas, ninguna tiene que ser la mejor, excepto algunos casos excepcionales.

Por tanto una buena arquitectura de Drupal debe concebir ese esfuerzo continuo en investigación de nuevos componentes y nuevas versiones para componentes existentes.

Presentación

Seguramente la gente no tiene claro lo que significa la palabra arquitectura unida a un proceso de desarrollo y despliegue ágil.

Intentaré resaltar la complejidad arquitectónica del modelo y hacer mención de todo lo que puede estar involucrado en una arquitectura de portales.

El producto elegido es Drupal, pero no es Drupal el centro de la arquitectura, sino un enclave en la misma.

Una buena arquitectura debe poder adaptarse a otro producto sin complejidad excesiva y manteniendo su base firme.

Vamos a describir todo lo que consideramos que es arquitectura. Para ello vamos a ir de la parte de sistemas avanzando hacia un desarrollo y terminando en una comunidad de portales.

Cinco Enclaves

q.- Enclaves arquitectónicos : La relación de dichas necesidades con la de los componentes a utilizar es arquitectura

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.

i.- Enclaves arquitectónicos : La relación entre componentes comunes para los portales es arquitectura

¿ 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.

p.- Enclaves arquitectónicos : La decisión de minimizar la documentación y agrupar las necesidades comunes es arquitectura

¿ Cómo se puede minimizar la documentación ? De qué manera podemos acercarnos más a los problemas de forma que los documentos sean ágiles y sencillos de interpretar.

Debemos simplificar el sistema. Debemos olvidarnos de todos las metodologías como Uml u otras que lo único que han conseguido es complicar su representación y acercarla al programador o ni eso, sino enfatizar la necesidad de un puesto intermedio que las interprete.

Demos simplicidad al asunto, apostemos por un nuevo aire en un sistema sencillo de componentes.

Esta metodología ha sido una de las partes de la arquitectura defendida ante la entidad independiente Red.es perteneciente al Ministerio de Industria de España.

Les presento un sistema de documentación fuera de lo normal :

Metodologías ágiles - Sistema de documentación

Hemos conseguido desligarnos de documentar todos los componentes, auto asociamos requisitos a componentes y nos centramos exclusivamente en el negocio del cliente.

Simplificamos el modelo. Y esta simplificación es arquitectura.

d.- Enclaves arquitectónicos : La interrelación entre distintos sistemas es arquitectura.

Una visión global que permita aunar las necesidades requeridas y la mejor satisfacción de las mismas con los sistemas actuales implica un enfoque adecuado para el rendimiento y futuro dimensionamiento del portal.

Poder utilizar otras herramientas como Apache Solr para poder gestionar las búsquedas y los filtros es una decisión que permitirá a nuestros portales rendir a un nivel mejor que con la estructura de búsqueda de Drupal.

Delegar en otros productos y utilizar lo módulos como contenedores de información y configuración es un acertado enfoque ya seguido por Drupal, desde el famoso Jquery hasta otros módulos que permiten utilizar productos o incluso servicios para poder desplegar su funcionalidad.

Acquía ofrece Apache Solr como servicio, por ejemplo.

Es una de tantas formas de aunar esfuerzos y visualizar el éxito del sistema como una interrelación.

Por tanto hacer una buena arquitectura implica hacer una buena relación con las posibilidades de cada momento y ser consciente que el estado del arte de dichas relaciones está cambiando continuamente, que está directamente relacionado con la versión actual de Drupal y que cualesquiera otras mejoras en otros componentes pueden decantar que nuestra arquitectura se quede obsoleta.

Es por ello que un estudio continuo del estado del arte de los sistemas es imprescindible para un adecuado enfoque arquitectónico con Drupal.

e.- Enclaves arquitectónicos : La elección de los componentes es arquitectura

Es fundamental un correcto estudio de los módulos necesarios antes de decidir cualquier desarrollo adicional.

Es trascendente un enfoque multi portal en cuanto a los módulos y componentes seleccionados.

Será muy importante la valoración de componentes comunes, no sólo los suministrados por Drupal, sino categorías, vistas, tipos de datos definidos que puedan simplificar los futuros desarrollos.

Es por todo ello, que un enfoque de arquitectura orientado a componentes es una de las claves del éxito del producto.

La tranquilidad de conocer que dicha funcionalidad ya está solucionada por el componente X, permite afrontar los desarrollo como si de un gran Lego se tratase, conocer qué piezas están disponibles y tener ejemplo directo de cómo esas piezas se interrelacionan.

Por todo ello el enfoque dado a un portal debe ser una parte más de la arquitectura.

No debemos aislar el desarrollo de dicho portal de la implementación de todos los portales.

Por tanto habrá componentes comunes y componentes específicos para ese portal.

Estos componentes podrán ser físicos y lógicos.

Sean componentes físicos todos los aportados por Drupal, por tanto físicamente atribuibles, como pueden ser módulos, temas, plantillas, etc.

Y componentes lógicos los generados por el producto a partir de ellos, como pueden ser Bloques , Vistas y también los mismos Módulos , Temas y Plantillas.

Una buena arquitectura debe considerar los componentes existentes comunes para minimizar los desarrollos posteriores y aunar esfuerzos en la lucha por la calidad final del producto.

Por tanto el estudio continuo de módulos y la documentación diaria de componentes seleccionados y desarrollados se considera crucial para que la arquitectura desplegada sea exitosa y aproveche correctamente las ventajas del producto.

Como se puede observar, esta metodología de componentes va más allá de Drupal. Sea este un producto, pero la filosofía de control documental y del estudio del arte continuo de posibilidades de implementación es y será aplicable a cualesquiera productos que estén enfocados en modo de componentes, en modo bazar, como suele estar planteado siempre el software libre.

Arquitecto Ricardo Cabello Torres

Estoy a disposición laboral para trabajar como Arquitecto Metodologías Ágiles Drupal o bien ofrecer mis servicios de diseño de portales en Portales Profesionales.

Invito a que conozcan a su vez un enfoque revolucionario de posicionamiento basado en arquitectura : El mejor posicionamiento - Brqx

Es un placer compartir con ustedes mis inquietudes en la sociedad y mi lucha unánime por un mundo mejor. Les invito a conocer Costumbres Sociales Actuales - Brqx.

También si les gusta el coleccionismo de calidad, les invito a participar en proyectos como Mis Palillos o Mis presentaciones.

Sin otro particular, gracias por tu visita.

Facetas de Drupal - Enclaves del Éxito

a.- Enclaves arquitectónicos : La definición de la estructura del producto es arquitectura
b.- Enclaves arquitectónicos : La relación con otros productos que permitan un mejor despliegue es arquitectura
c.- Enclaves arquitectónicos : La correcta definición de necesidades a nivel de sistema es arquitectura
d.- Enclaves arquitectónicos : La interrelación entre distintos sistemas es arquitectura.
e.- Enclaves arquitectónicos : La elección de los componentes es arquitectura
f.- Enclaves arquitectónicos : La definición de los nombres de los componentes es arquitectura
g.- Enclaves arquitectónicos : La presentación y composición de dichos componentes también es arquitectura
h.- Enclaves arquitectónicos : La categorización de la ruta de los componentes es arquitectura
i.- Enclaves arquitectónicos : La relación entre componentes comunes para los portales es arquitectura
j.- Enclaves arquitectónicos : La decisión de reutilización de componentes es arquitectura
k.- Enclaves arquitectónicos : La gestión de los componentes y el control de los portales es arquitectura
l.- Enclaves arquitectónicos : La necesidad de conocimiento de los componentes disponibles es arquitectura
m.- Enclaves arquitectónicos : Los parámetros de usabilidad y seguridad aplicados a los componentes elegidos son arquitectura
n.- Enclaves arquitectónicos : La capacidad para prevenir los cambios y la adaptación del sistema al futuro es arquitectura
o.- Enclaves arquitectónicos : La capacicidad de abstracción que permite interpretar un sistema complejo de forma simple, es arquitectura
p.- Enclaves arquitectónicos : La decisión de minimizar la documentación y agrupar las necesidades comunes es arquitectura
q.- Enclaves arquitectónicos : La relación de dichas necesidades con la de los componentes a utilizar es arquitectura

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.

Distribuir contenido