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

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.

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.

h.- Enclaves arquitectónicos : La categorización de la ruta de los componentes es arquitectura

La informática es una rueda que rara vez deja de ser redonda, sino que se disfraza con múltiples capas.

Durante años se ha identificado los componentes por una ruta específica, así pues en múltiples sistemas se han organizado niveles jerárquicos para organizarlos.

Esos mismos niveles indicaban una forma inequívoca de localizar un componente, como puede ser por ejemplo el fichero host en un sistema windows localizado en :

\System32\Drivers\Etc

Cada uno de estos parámetros aportaba valor y permite organizar el sistema.

También suponía una forma de localizar dicho archivo.

Buscando sistemas algo más potentes, podemos conseguir con enlaces simbólicos tanto en Unix como en particiones NTFS de windows distintos formas de acceder a dicho archivo.

Esa estructura tan estricta desaparece con el formato de BBDD, donde para localizar el contenido ya no es tan importante la ruta, sino más bien los campos por los que se busque.

Veamos un ejemplo :

/tierra/animales/domesticos/perro/caniche

Su categorizacion sería :

Planeta / Ser Vivo / Tipo Animal / Animal Domestico / Tipo Perro

Haciendo una query con estos vocablos sin duda accedemos al contenido, por tanto ya no es tan importante la ruta.

Pero tal como adelanté, volvemos a la misma rueda cuando lo que usamos es una URL.

Vuelve a ser importante la ruta.

Incluso con un sistema de meta tags, acaba siendo trascendente la ruta de los contenidos.

Hace un tiempo tenía un sueño, poder categorizar las rutas en razón a meta tags.

Les invito a ver lo que pedía en su día.

Brqx dream: Traceabilidad documental automatizada por taxonomías

Hoy en día esto ya es posible.

Y es más importante aún que esta idea ya irá directamente en el núcleo de Drupal en se versión 7.

Toda esa información categorizada nos permite llevar un control de los componentes de nuestro site, y a su vez aportar un valor documental extraordinario con objeto de fomentar políticas de posicionamiento.

Si, la capacidad de tracear rutas unida a la funcionalidad de abstracción de contenidos similares propia de Drupal con mod_rewrite incrementa notoriamente el valor documental de nuestro site.

Estos parámetros de traceabilidad ya fueron declarados y explicados en uno de mis primeros portales:

Idea Traceabilidad - Brqx

Sin duda ha sido una de mis obsesiones y de mis mejores aportes de arquitectura a todos y cada uno de los portales implementados.

Por tanto definir adecuadamente la ruta y el nombre de los contenidos con módulos como pathauto , token y auto_nodetitle es una labor de gran importancia para cualquier planteamiento arquitectónico con Drupal.

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

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