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

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 :

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.

f.- Enclaves arquitectónicos : La definición de los nombres de los componentes es arquitectura

Es una norma universal en la programación, el intentar identificar la funcionalidad de las variables, las funciones, las aplicaciones,etc.

Esta identificación implica un nombramiento buscando la simplicidad y la caracterización máxima de los componentes.

El objetivo es luchar por un sistema mantenible que implique el menor esfuerzo para conocer las funcionalidades implementadas.

Por tanto, aparte de apostar por una gestión documental, también debemos considerar el nombramiento adecuado de los componentes como otro punto importante para mantener una arquitectura adecuada.

Por ejemplo, en una vista deberíamos sólo con el nombre de la misma conocer :

- Que tipo de vista es, enfocando el tipo al formato de la misma.

- Qué contenidos va a mostrar

- Si va a recibir parámetros y cuántos serían

- Si va a pertenecer a un tipo de datos o es una vista general

Toda esta información debería dárnosla el nombre de la vista.

¿ por qué es importante seguir sistemas de codificación completa ?

Porque nuestro objetivo es poder reutilizar esas mismas vistas y poder ser capaces de diagnosticar si su funcionalidad nos es válida o no sin tener que llegar al momento de edición.

Sin duda éste y muchos otros parámetros arquitectónicos empiezan a vislumbrar su sentido cuando el número de vistas y el número de portales se incrementa notoriamente.

No es nada nuevo, estas técnicas están ya contrastadas en metodologías de sistemas, en buenas prácticas de programación, en enfoques metódicos tan actuales como CMMI e Itil, son características comunes de cualesquiera arquitecturas.

o.- Enclaves arquitectónicos : La capacicidad de abstracción que permite interpretar un sistema complejo de forma simple, es arquitectura

Hemos sido todos participes de una documentación inadecuada en la mayoría de los proyectos. Excesiva, nada práctica, demasiado completa.

El objetivo es preparar una documentación más cercana a las necesidades del cliente, una documentación que se abstraiga de detalles innecesarios y se acerque a los objetivos reales de cada proyecto.

Contamos con un sistema que permite representar con sencillez casi cualquier proyecto web. Esta metodología está parcialmente detallada en nuestra web de Metodologías Ágiles.

Queremos minimizar todos los documentos que se involucran en un proyecto y transformar el sistema de documentación tradicional en un sistema mucho más ágil compuesto de documentos totalmente operativos y un sistema documental que aporte toda la información totalmente categorizada y que soporte los aspectos documentales de cada proyecto.

Es hora de olvidarse de documentos Pdf, Word de innumerables páginas. Es el momento para enfocar adecuadamente las dudas y desplegar un sistema que permita agilizar las consultas, evitar redundancia y apostar por la filosofía de "documentos vivos".

Este papel es vital para una buena arquitectura. Debemos analizar las necesidades de cada rol y preparar una documentación acorde a los mismos y envuelta en un sistema ágil, intuitivo y muy bien categorizado.

Por tanto la definición de las abstracciones necesarias para lograr este objetivo tanto a nivel de contenidos como a nivel de documentación final será otro de los parámetros a considerar en una arquitectura de Portales.

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.

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.

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
[ZT 24C 128G SSD_4-SATA_1] - (CDN:XX) [SP:PM]30-Sep-2016 - 23:46:00 * - - - * Carga: 1.8161 ==> segundos - Mem:307.75 Mb/12778M