Busqueda local

Loading

jueves, 25 de noviembre de 2010

Arquitectura de software y Arquitecto de software.

La palabra arquitectura se puso de moda en el medio informático hace relativamente poco tiempo, recuerdo que la leí por primera vez en algún sitio de Microsoft y me pareció algo extravagante, ya que en aquel entonces yo no sabía lo que significaría este término en mi vida profesional. Aun hoy en día cuando debo presentarme y se hace alusión a que en mi trabajo me desempeño como arquitecto de software, me siento algo incomodo. Tal vez porque el termino ha sido idealizado por quienes estamos inmersos en hacer aplicaciones en el plano profesional.
Y claro no puedo olvidar mencionar a Martin Fowler y su libro Patterns of Enterprise Application Arquitecture. El mismo Martin menciona una anécdota donde comenta esta misma incomodidad, en un articulo donde habla del tema.
http://www.martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf
Así que haciendo alusión a su escrito, en este post quiero hablar de la arquitectura de software.
Según él, la definición puede ser tan simple como querer agregarle algo de glamur cuando debemos decir que se requiere un diseño, pero la verdad es que no solo se trata de ponerle ese toque.
"En la mayoría de los proyectos de software exitosos, los desarrolladores expertos que trabajan en ese proyecto tienen un entendimiento compartido sobre el diseño del sistema. Este entendimiento compartido se llama 'arquitectura'.
Si desean leer todo el articulo visiten la dirección, en este post voy a presentar algunos párrafos que me parecen interesantes.
En el escrito original el transcribe un párrafo de un colega suyo llamado, Ralph Johnson que dice así:
el concepto de más alto nivel de un sistema en su entorno. La arquitectura de un sistema de software (en cualquier momento en el tiempo) es su organización o estructura de los componentes importantes que interactúan a través de interfaces, y estos componentes se componen de componentes e interfaces sucesivamente más pequeños
Tras lo cual continúa diciendo:
No existe un "concepto de más alto nivel de un sistema". Los clientes tienen un concepto distinto a los desarrolladores. A los clientes no les importa toda la estructura de componentes importantes. Entonces, quizás la arquitectura sea el concepto de más alto nivel que tienen los desarrolladores sobre un sistema en su entorno. Olvidemos a los desarrolladores que sólo entienden sus piezas pequeñas. La arquitectura es el concepto de más alto nivel de los desarrolladores expertos.
Tras analizar el concepto hace una clasificación de dos tipos de arquitecto: El que toma todas las decisiones importantes por el equipo, la mente maestra que debe prevenir todo y el que se involucra y le permite a los desarrolladores participar activamente. El que ayuda a salir del atolladero, el que organiza los requerimientos y se preocupa por que los miembros del equipo crezcan, para que no sea él, el único que toma las decisiones.
Para mí un arquitecto debe ser del segundo tipo, esto representa un reto constante, ya que la tecnología evoluciona muy rápido y para poder está a la altura de los requerimientos de las empresas de hoy en día, no podemos descansar, diario sale alguna nueva propuesta, que debemos conocer y valorar, para estar en la posibilidad de emplearla si algún proyecto así lo requiriera.
El escrito concluye decisión que: el valor de un arquitecto es inversamente proporcional a la cantidad de decisiones que tiene que tomar.

No hay comentarios:

Publicar un comentario