"El Arquitecto de Software"

El TAO del Arquitecto de Software

2005-12-12T19:50:00.001+01:00

He encontrado en la página de arquitectura de IBM un artículo de Philipe Kruchten que puede salvar de la locura a más de un arquitecto. Se trata de una lectura muy personal del Tao Te Ching de Lao-Tsu. Puede parecer una ida de olla, pero para alquien que haya llevado unos añitos en la profesión puede abrirle mucho los ojos...

El arquitecto observa el mundo pero confia en su visión interna.
Él acepta que las cosas vengan y vayan.
Su corazón es abierto como el cielo.
El arquitecto no habla, actúa.
Cuando esto cocurre, el equipo dice:
"Increible: lo hicimos, y por nosotros mismos"
Cuando un gran arquitecto está al frente,
el equipo tiene claramente presente que él existe.
Después, lo mejor que hay es un lider que es querido.
Después, uno que es temido.
Lo peor, uno que es despreciado.
Un buen viajante es aquel que no tiene planes fijos y no tiene un propósito de hasta dónde llegar.
Un buen artista permite que su intuición le lleve dónde esta quiera.
Un buen científico se ha liberado a si mismo de conceptos y mantiene su mente abierta a lo que es.
Por lo tanto el arquitecto está abierto a todo el mundo y no rechaza a nadie.
El está dispuesto a usar todas las situaciones y no desperdicia nada.
A esto se le llama personificar la luz.
Si quieres reducir algo, debes permitir que primero se expanda.
Si quieres deshacerte de algo, debes permitir primero que florezca.
Si quieres coger algo, debes permitir que sea dado.
A esto se le llama la sutil percepción de la forma que tienen de ser las cosas.
Lo suave vence a lo duro.
Lo lento vence a lo rápido.
Haz que tu trabajo permanezca como un mistario.
Sólo muestra los resultados.
Cuando se pierde el proceso, queda el saber hacer.
Cuando se pierde el saber hacer, quedan las reglas.
Cuando se pierden las reglas, queda el ritual.
El ritual es el inicio del caos.
El arquitecto se preocupa con la profundidad y no con la superficie,
con el fruto y no con la flor.
El arquitecto deja que las cosas pasen.
Él da forma a las cosas con forme vienen.
Él se mantiene al margen y deja que el diseño hable por sí mismo.
El arquitecto se entrega a cualquier cosa que aporte el momento.
El sabe va a marcharse y no tiene nada que le haga estperar:
no hay ilusiones, no hay resistencia en su mente.
Él no retrasa nada el proyecto, por lo tanto está listo para partir.
Como un hombre está listo para dormir después de un duro día de trabajo.
El mejor camino es fácil, sin embargo los programadores prefieren los caminis laterales.
Estate alerta cuando las cosas están desequilibradas.
Permanece centrado en el diseño.
La fuerza del arquitecto es como lo siguiente.
El deja que las cosas vengan y vayan fluidas, sin deseo.
El nunga espera resultados;
por lo tanto nunca se decepciona;
por lo tanto, su espíritu nunca envejece.
Aquellos que conocen no hablan.
Aquellos que hablan no conocen.
(Aquellos que no tienen ninguna pista todavía debaten acerca del proceso.
Aquellos que la tienen hacen.)
El arquitecto está contento de servir como un ejemplo y no de imponer su deseo.
Es agudo, pero no perfora.
Directo, pero ágil.
Resplandeciente, pero no deslumbrante para los ojos.
Si quieres ser un gran lider, deja de intentar controlar.
Olvidate de planes fijos y conceptos y el equipo se governará a si mismo.
Cuantas más prohibiciones tengas, más indisciplinado será el equipo.
Cuanto más coercitivo seas, el equipo será más inseguro.
Cuanto más ayuda externa utilices, menos autosuficiente será el equipo.

Arquitectura: Comunicar, Comunicar, Comunicar...

2005-12-06T22:02:00.000+01:00

Generalmente, la producción y explotación de sistemas de software son actualmente unas actividades complejas y de elevado riesgo. Para afrontar es importante poder anticipar ciertas decisiones relacionadas con el diseño técnico que puedan tener un impacto importante.

El IEEE Std 1471-2000 se centra en la descripción de la arquitectura de sistemas intensivos en software. Su propósito consiste en facilitar la posibilidad de expresar y comunicar las arquitecturas y de ese modo sentar unas bases para estandarización de sus elementos y las prácticas asociadas para su descripción. La descripción de la arquitectura tiene múltiples dimensiones, en función de las necesidades que tienen los diferentes 'stakeholders' (implicados clave). Cada 'stakeholder' tiene un conjunto de 'concerns' (inquietudes) respecto a la arquitectura. El arquitecto debe seleccionar un conjunto de 'viewpoints' que cubran dichas inquietudes y generar diferentes vistas de la arquitectura que se ajusten a los 'viewpoints' escogidos.

Es muy interesante observar que el primer paso realmente serio en cuestiones de arquitectura de software vaya en la línea de establecer un mecanismo de descripción y que pone a los implicados clave como centro de esta descripción. No es posible gestionar la complegidad de los sistemas ni lo riesgos para su mantenimiento o evolución sin hacer partícipes de ellos a los implicados clave en la organización. Los implicados clave mínimos definidos por IEEE son:

Los usuarios
Los compradores, clientes o propietarios (acquirers)
Los desarrolladores
Los mantenedores

Por otra parte los 'concerns' mínimos a cubrir deben ser:

El propósito o misión del sistema
Lo apropiado del sistema para cubrir la misión.
La viabilidad de desarrollar el sistema.
Los riesgos del desarrollo y las operaciones del sistema para cada implicado clave.
La capacidades de mantenimiento, despliegue y evolución del sistema.

En definitiva, la descripción de la arquitectura está hecha para comunicar: debe centrarse en comunicar información referente a las inquietudes de los usuarios y debe permitir comunicarse con los diferentes implicados clave de la organización. ¿Beneficios buscados? Abordar la complegidad y minimizar riesgos.

Arquitectura de software y beneficios buscados

2005-11-30T19:14:00.000+01:00

El SEI (Software Engineering Institute) define el concepto de Arquitectura de Software de la siguiente manera:

La arquitectura de software de un sistema es la estructura o estructuras del sistema, las cuales comprenden los elementos de software, las propiedades externamente visibles de estos elementos y sus relaciones entre ellos.

El arquitecto de software debe impulsar la definición de aquellos requerimientos que estén relacionados con dichas estructuras, propiedades externas y relaciones entre elementos. El SEI propone gestionar y definir estos requerimientos a través de lo que denomina 'Atributos de Calidad de los Sistemas' los cuales son descritos mediante escenarios. La forma de definir estos escenarios se basa en:

Establecer los elementos del sistema involucrados en el requerimiento (o el sistema completo), teniendo en cuenta posibles condicionantes contextuales.
Identificar los estímulos que pueden recibir dichos elementos y el orígen de los mismos.
Acordar la respuesta deseada, definiendo la medida por la cual se considera el requerimiento cubierto.

Por ejemplo:

Respuesta
Orígen	Los usuarios...
Estímulo	...inician 1.000 transacciones por minuto de forma estocástica...
Artefacto	...en el sistema de pagos bajo condiciones normales...
...y las transacciones son procesadas...
Medición	...en un tiempo medio de 2 segundos.

Bajo mi punto de vista la SEI hace un excelente trabajo a la hora de proponer cuales deben ser los principales atributos que debe centrarse la arquitectura:

Atributo	Estímulo	Respuesta
Disponibilidad	Fallo	Fallo enmascarado o reparado.
Modificabilidad	Cambio	Cambio construido, testeado y desplegado entiempo y presupuesto.
Rendimiento	Evento	Respuesta generada dentro de las limitaciones establecidas.
Seguridad	Ataque	El sistema detecta, resiste o se recupera de un ataque.
Testabilidad	Entrega	El equipo detecta las incidencias.
Usabilidad	Petición Usuario	El usuario recibe el feedback apropiado y asistencia.

En el libro "Software Architecture in Practice" de Addison Wesley, además de entrar en explicar estos conceptos, nos permite movernos desde el mundo Conceptual al mundo Lógico (siguiendo terminología Zachman) aportando un conjunto de tácticas que nos perrmiten definir modelos para abordar los reqerimientos asociados a los atributos de calidad.

¿Para qué sirve la Arquitectura Empresarial?

2005-11-27T22:13:00.000+01:00

Existe un momento en que los sistemas software de una compañía han crecido de tal manera que el éxito de la estrategia de Sistemas ya no depende únicamente de la capacidad de analizar, diseñar, desarrollar, desplegar y mantener las diferentes soluciones tecnológicas implantadas en la organización. Llegado este punto, pasa a ser de gran valor una visión que permita adaptar las soluciones a los procesos empresariales cambiantes.

La capacidad de adaptación dependerá en gran medida de las características internas de los sistemas existentes pero también en la capacidad de la organización para gestionar el proceso de cambio. Este proceso de adaptación requiere de tres pasos básicos:

Comunicar de forma eficaz a los implicados clave la situación actual de las soluciones. Teniendo en cuenta los puntos fuertes, débiles, las amenazas y las oportunidades respecto a las necesidades actuales y futuras.
Definir un mapa de transformación de las soluciones en base a las nuevas necesidades que pueda ser comprendido y acordado por todos los implicados clave.
Llevar a cabo una gestión que asegure el cumplimiento del mapa de transformación acordado, contrastando la calidad y el éxito del mismo.

La arquitectura empresarial consiste en ser "process owner" de este proceso de adaptación tecnológico.