EspañaInglaterraAlemaniaItaliaPortugalFranciaEspañaInglaterraAlemaniaItaliaPortugalFrancia
Enseñar al mundo nociones de arquitectura, complejidad y formas de actuar

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

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.

b.- Enclaves arquitectónicos : La relación con otros productos que permitan un mejor despliegue es arquitectura

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.

n.- Enclaves arquitectónicos : La capacidad para prevenir los cambios y la adaptación del sistema al futuro es arquitectura

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.

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.

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.

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
Distribuir contenido