a0002
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
- m.- Enclaves arquitectónicos : Los parámetros de usabilidad y seguridad aplicados a los componentes elegidos son arquitectura
- a.- Enclaves arquitectónicos : La definición de la estructura del producto es arquitectura
- l.- Enclaves arquitectónicos : La necesidad de conocimiento de los componentes disponibles es arquitectura
- g.- Enclaves arquitectónicos : La presentación y composición de dichos componentes también es arquitectura
- c.- Enclaves arquitectónicos : La correcta definición de necesidades a nivel de sistema es arquitectura
m.- Enclaves arquitectónicos : Los parámetros de usabilidad y seguridad aplicados a los componentes elegidos son 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 :
El objetivo de dicha metodología es minimizar las opciones disponibles ajustándolas a las necesarias.
A su vez aplicamos la metodología
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.
a.- Enclaves arquitectónicos : La definición de la estructura del producto es arquitectura
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.
l.- Enclaves arquitectónicos : La necesidad de conocimiento de los componentes disponibles es arquitectura
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.
g.- Enclaves arquitectónicos : La presentación y composición de dichos componentes también es arquitectura
Por defecto Drupal presenta los componentes en formato de lista.
A su vez nos proporciona Bloques , Vistas y otros objetos para poder desplegar la información en nuestros portales. La decisión de cómo hacer ese despliegue y la capacidad de modificarlo está relacionado con una adecuada arquitectura de presentación de contenidos.
Desde que existen estos productos, desde la época del Php Nuke y otros similares , se ha distinguido entre un formato reducido del componente, en Drupal conocido como Teaser, y un formato más ampliado donde se despliega todo su contenido, conocido como Body , Cuerpo , Full , Completo, etc.
De entrada disponemos de , al menos, tres variantes de presentación :
- Títulos
- Teasers
- Full
La idea es poder personalizar estos componentes acorde a la información que queremos mostrar en cada momento.
Drupal por defecto permite cortar por número de caracteres, incluso hay módulos que crean un campo aparte para los teasers.
Pero el módulo que nos da esa agilidad es Content Templates.
Este módulo nos permite personalizar la salida de nuestros componentes.
Este módulo permite crear sistemas de plantillas y como mejora aún, no se almacenan el BBDD, por tanto hablamos de componentes que pueden ser compartidos entre múltiples portales con los mismos tipos de usuario.
La decisión de cuando usar una plantilla o no es un factor trascendente de arquitectura.
A su vez los propios tipos de Drupal pueden relacionarse, tanto con enlaces como con inclusiones, es posible crear jerarquías complejas que conforman componentes más avanzados.
Esa composición, es un factor determinante de la arquitectura del portal.
Por tanto, la apariencia del portal no sólo se puede modelar con los propios objetos del mismo, sino también con los componentes creados por nuestra parte.
Considero que esta capacidad de crear componentes personalizados es una de las más poderosas facetas de Drupal.
El módulo de componentes y más aún la equiparidad entre campo y taxonomía aportada por otro fantástico módulo Content Taxonomy irán diréctamente en el núcleo de Drupal 7.
Es una prueba directa que nos informa de la importancia que tiene esta forma de desarrollar o de componer portales.
c.- Enclaves arquitectónicos : La correcta definición de necesidades a nivel de sistema es arquitectura
El producto en cuestión es bastante complejo, pero esa complejidad es un desafío continuo y una base constante de la capacidad del mismo.
Sin duda un producto sencillo, difícilmente puede ser un producto de calidad, pues a medida que se va incrementando el abanico de funcionalidades, va creciendo en igual medida su complejidad.
Es por ello que debemos considerar una buena elección de módulos, de componentes.
Es transcendental analizar las necesidades hardware para los portales, la memoria y la configuración de los sistemas. Los mecanismos de caché. Los módulos que puedan incrementar esa eficiencia.
Y por supuesto hacer un enfoque global considerando las necesidades actuales y el estado del arte del producto.
Si usamos una versión 5.x sabemos que no podemos usar una versión de php 5.3. Se ha comprobado inestabilidad con módulos como Content Templates. As su vez hay módulos que únicamente están para otra versión, otros que no mantienen continuidad.
Es importante hacer estudio continuo de todos los módulos y opcodes que requiere el producto.
A su vez es trascendente considerar que un sistema no es sólo Drupal.
Hay grandes avances para conseguir un sistema más eficiente tanto por parte de Acquia como por otras empresas como Chapter 3 que invitan a apostar por un sistema con Mercury.
Pero en ese sistema es muy complejo unirlo a un panel de control . De momento no hay instrucciones precisas para instalar Mercury con Whm/Cpanel, por tanto debemos considerar las necesidades del portal para plantearnos si realmente podemos usar Mercury entero o bien sólo Varnish, Memcached, Pressflow, etc. Es una prueba de que el estado del arte de estas tecnologías está continuamente cambiando, por tanto es muy importante tenerlo en cuanta para ajustar las necesidades del sistema a las configuraciones más adecuadas para el mismo.
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
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 :
El objetivo de dicha metodología es minimizar las opciones disponibles ajustándolas a las necesarias.
A su vez aplicamos la metodología
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.
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.
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.
